Climbexion revision control voor softwarewerkplaatsen Henk ...

Climbexion 

revision control voor softwarewerkplaatsen 

Henk Pietersma 

2008-11-05

Inhoudsopgave 

1 Inleiding............................................................................................................................................5 

1.1 Achtergrond..............................................................................................................................5 

1.2 De organisatie...........................................................................................................................6 

1.2.1 Inleiding............................................................................................................................6 

1.2.2 Projects en Products..........................................................................................................7 

1.2.3 De teams..........................................................................................................................10 

1.2.4 Het werk..........................................................................................................................11 

1.2.5 Enige slotopmerkingen...................................................................................................13 

1.3 De televisie als bedrijf............................................................................................................20 

1.4 Televisie, de software..............................................................................................................25 

1.4.1 Architectuur en component modellen.............................................................................25 

1.4.2 Robuuste overgangen......................................................................................................26 

1.4.3 Folder structuur en builds ..............................................................................................28 

1.4.4 Afbakening NXP ............................................................................................................29 

1.4.5 Diversity .........................................................................................................................30 

1.4.6 Koala / Horcom...............................................................................................................32 

1.4.7 Power modes en hardware die geen deel uitmaakt van het audio/video platform..........37 

1.4.8 Pumps en pump engines..................................................................................................38 

1.4.9 MIPS recovery................................................................................................................40 

1.4.10 Test binaries ..................................................................................................................41 

1.4.11 Tools..............................................................................................................................41 

1.4.12 Version control.............................................................................................................42 

1.4.13 Instrumentation.............................................................................................................43 

1.4.14 Slot opmerkingen..........................................................................................................44 

1.5 Televisie, de hardware............................................................................................................48 

1.6 De testplek..............................................................................................................................50 

2 Schets van het revision control system...........................................................................................52 

2.1 De basis...................................................................................................................................52 

2.2 Begrippen................................................................................................................................54 

2.2.1 Basisstructuur..................................................................................................................54 

2.2.2 De organisatie van het geheel aan drawers.....................................................................62 

2.2.3 De organisatie van pools.................................................................................................67 

2.2.4 De organisatie van snapshots..........................................................................................68 

2.2.5 Other-focused files..........................................................................................................71 

2.2.6 Envelopes........................................................................................................................75 

2.2.7 Baseline supplements, external envelopes......................................................................79 

2.2.8 Resources........................................................................................................................81 

2.3 Metadata..................................................................................................................................84 

2.3.1 Inleiding..........................................................................................................................84 

2.3.2 Attributes, soorten en maten............................................................................................84 

2.3.3 Templates, wizards, pretty printing, macro's, en zo........................................................85 

2.3.4 File-type..........................................................................................................................87 

2.3.5 Entity type.......................................................................................................................90 

2.3.6 Restricties op kins...........................................................................................................92 

2.3.7 Classifications ten behoeve van export limitations.........................................................92 

2.3.8 Original en neighbor.......................................................................................................97 

2.3.9 Base en labored...............................................................................................................98 

2.3.10 Kin references...............................................................................................................98 

2.3.11 Attributes van drawer, package, pool, machine.............................................................98 

2.3.12 Tenslotte........................................................................................................................99

Climbexion, revision control voor softwarewerkplaatsen datum: 2008-11-05 

2.4 Werkwijzen...........................................................................................................................100 

2.4.1 Merging.........................................................................................................................100 

2.4.2 Synchronisatie...............................................................................................................106 

2.4.3 Synchronisaties tussen satellite en working-tree...........................................................107 

2.4.4 Het werken met team-drawer, transfer-drawer en satellite...........................................109 

2.4.5 Een geabonneerd package inlijven................................................................................115 

2.4.6 Het overnemen (adopt) van envelopes uit een sister-project........................................116 

2.4.7 Undo envelope...............................................................................................................118 

2.4.8 synchroniseren van eigen packages met die van een sister-project (adopt merge).......119 

2.4.9 Gemeenschappelijk beheerde packages........................................................................122 

2.4.10 Baseline samenstellen.................................................................................................123 

2.4.11 Project dependencies...................................................................................................124 

2.4.12 Informatie, werkelijkheid, gedistribueerd systeem.....................................................125 

2.5 Planning & Tracking en Repositories...................................................................................131 

2.5.1 Introductie.....................................................................................................................131 

2.5.2 Relaties met envelopes..................................................................................................133 

2.5.3 Composite Activities.....................................................................................................134 

2.6 Builds en Repositories..........................................................................................................137 

2.6.1 De invloed van builds op Climbexion...........................................................................137 

2.6.2 First class citizens of tarballs........................................................................................144 

2.6.3 Build Forest...................................................................................................................146 

2.6.4 Build bij NXP................................................................................................................148 

2.6.5 Versnipperingen.............................................................................................................149 

2.6.6 Other-focused build results...........................................................................................152 

2.6.7 Conclusies.....................................................................................................................153 

2.6.8 Build extra's. DianPush Build.......................................................................................153 

2.7 Security.................................................................................................................................168 

2.7.1 Security entiteiten ........................................................................................................168 

2.7.2 Security doelen en middelen.........................................................................................169 

2.7.3 Gentlemen agreements..................................................................................................172 

2.8 Overige aspecten...................................................................................................................176 

2.8.1 Status en Progressie......................................................................................................176 

2.8.2 Het top package.............................................................................................................178 

2.8.3 Locks.............................................................................................................................179 

2.8.4 Notifications..................................................................................................................184 

2.8.5 Pool operaties................................................................................................................185 

2.8.6 Importeren, Exporteren.................................................................................................188 

2.8.7 Virtualisatie...................................................................................................................191 

2.8.8 Begrenzen?....................................................................................................................192 

2.8.9 Gebruikersvriendelijke? id's..........................................................................................197 

2.8.10 Losse eindjes...............................................................................................................200 

2.9 Slotopmerkingen...................................................................................................................202 

3 Methodische probleem beschrijving.............................................................................................206 

3.1 Inleiding................................................................................................................................206 

3.1.1 ORM..............................................................................................................................206 

3.1.2 Problem frames.............................................................................................................206 

Pagina: 3 / 230


3.1.3 JSP.................................................................................................................................207 

3.1.4 HCI................................................................................................................................208 

3.2 Context diagram....................................................................................................................210 

3.3 Repository Database.............................................................................................................215 

3.3.1 Envelopes......................................................................................................................215 

3.4 Het administrator subprobleem (zeer voorlopig)..................................................................218 

3.4.1 Interface Administrator machine / SCM machine.........................................................221 

3.4.2 Interface Administrator / Machine................................................................................222 

4 Licentie.........................................................................................................................................230 

Pagina: 4 / 230


1 Inleiding 

1 Inleiding 

1 Inleiding 

1.1 Achtergrond 

Sinds 1 oktober 2008 ben ik met pensioen gegaan. Voordien werkte ik bij het softwarehuis “TASS 

Software professionals” in Eindhoven, en was gedetacheerd bij NXP en droeg bij aan software 

voor digitale televisies. 

Dus maar wat hobbyen. In mijn jonge jaren heb ik me weleens bezig gehouden met programma 

beheer op IBM mainframes. Dit was gebaseerd op “partitioned datasets” en overdrachten van de 

afdeling programma-ontwikkeling naar de afdeling productie. Bij het openen van een programma in 

de ontwikkel-omgeving werd het programma eerst gezocht in de development dataset, en dan in de 

production dataset. In de productie-omgeving werd uitsluitend in de production dataset gezocht. 

Sindsdien heeft dergelijk beheer altijd mijn belangstelling gehad. Vandaar deze poging om een 

revision control system te definiëren. Trouwens, ik vindt het leuk om dingen opnieuw uit te vinden. 

Er zijn behoorlijk wat systemen om software op te bergen. Ik verwacht dan ook dat, als ik mijn 

gedachtespinsels op een website zet, dat de dingen dan niet ogenblikkelijk uit mijn handen gerukt 

zullen worden omdat iedereen erom zit te springen. Anderzijds hoop ik toch ook dat anderen mijn 

studie belangwekkend vinden. 

Voor mijn analyses heb ik mijn kennis van de NXP afdeling gebruikt waar ik het laatst gewerkt heb. 

Hierop kun je echter niet blindvaren. Ik heb geen documenten of software mee naar huis genomen, 

geen interviews gehouden, of mensen gebeld als ik iets niet wist, kortom als ik iets niet wist heb ik 

mijn duim gebruikt. Als ik dacht dat precisie schadelijk kon zijn voor NXP of een klant, dan ben ik 

vaag gebleven, of heb maar wat verzonnen. 

Als het al geleerd is wat ik beschrijf dan is het in ieder geval kamergeleerdheid. Wees 

gewaarschuwd. 

Voor de domein beschrijving en het eisen pakket probeer ik Niam (tegenwoordig ORM) en 

Problem frames te gebruiken. Dergelijke specificaties heb ik tot nu toe nooit hoeven te maken, dus 

ik ben benieuwd of het lukt. 

Het systeem dat ik beschrijf heeft als belangrijkste kenmerk dat het niet triviaal is. Hopelijk is het 

niet een zuivere kopie van een bestaand systeem. Te hanteren methoden zijn beschreven in: 

1. "Information Modeling and Relational Databases. second edition" van Terry Halpin en Tony 

Morgan (Morgan Kaufmann Publishers ISBN: 978-0-12-373568-3) 

2. "Problem Frames, Analyzing and structuring software development problems" van Michael 

Jackson. (Addison-Wesley ISBN 0-201-59627-X) 

De taal waarin ik schrijf is Nederlands hoop ik. Als het mij lukt om mijn ideeën in redelijk 

Nederlands en begrijpelijk op papier te krijgen, kan ik ze altijd nog vertalen in slecht Engels. Voor 

de termen die te maken hebben met het revision control system, trouwens voor veel vaktermen, 

gebruik ik Engels, die zijn dus reeds “vertaald”. 

Pagina: 5 / 230


1 Inleiding 

1.2 De organisatie 


1.2.1 Inleiding 

In de jaren 1980-2010 heb ik onder meer deelgenomen aan diverse projecten voor Philips 

Semiconductors. Een van de dingen die toen opviel is de toewijzing van ontwikkelingen aan de 

diverse laboratoria. Ieder laboratorium kreeg een aandeel in een nieuw te ontwikkelen chips-set. 

Daar zullen best allerlei rationele argumenten voor geweest zijn, maar toch, ik denk dat de 

belangrijkste reden was dat ze verslaafd waren aan internationale samenwerking. En sindsdien heb 

ik eigenlijk nooit anders ervaren. 

Voor wat betreft de TV ontwikkeling bij de eeuw overgang: Phiiips SC (Semiconductors, later 

NXP) en Philips CE (Consumer Electronics) waarmee werd samengewerkt waren strikt 

georganiseerd in markt segmenten. Er waren teams die de low-end markt bedienden, teams voor de 

mid-range, en teams voor de high-end markt. Ik werkte in het high-end segment. Traditioneel wordt 

daar het maken van een televisie gezien als een edel handwerk, met nauwelijks concessies: goed is 

niet goed genoeg. Features ontstonden in het high-end segment, en vonden vandaar uit hun weg 

naar mid-range en low-end. Dit werd “down-draining” genoemd, en besloeg een aantal jaar. Ieder 

team had zijn eigen software stack en hardware range waarin de nieuwe functionaliteit werd 

aangebracht. In de periode dat ik er werkte vond feitelijk een integratie plaats van mid-range en 

high-end. Down-draining hield op te bestaan. Mid-range werd “uitgekleed” high-end, in ieder geval 

in mijn vakgebied: de software. 

De afdeling bij NXP in Eindhoven waarvoor ik werkte van 2002 tot in 2008 ontwikkelde software 

voor hybride analoge/digitale televisies. Technisch zijn het digitale televisies want analoge signalen 

worden zo snel mogelijk omgezet naar digitale stromen. Alle bewerkingen van decoderen tot het 

schrijven op een LCD of plasma scherm vinden plaats door de stroom te converteren van het ene 

digitale formaat in het andere (decoding), of door de digitale informatie te wijzigen (bewerking). 

Hybride zijn ze omdat ze zowel analoge video en audio input kunnen weergeven op beeldscherm en 

speaker, als ook digitale. Ook kunnen ze analoge output maken, door een digitale stroom om te 

zetten in een analoge, net voor hij de tv verlaat. 

Toen ik in 2002 door NXP werd ingehuurd, werd een belangrijk deel van de software ontwikkeld in 

Eindhoven, en een ander deel in Sunnyvale. In 2008 vindt het grootste deel van de ontwikkeling 

plaats in Bangalore en een klein deel in Eindhoven, en nog enige drivers in Hamburg. 

De software die NXP levert is bestemd voor hun one-chip TV. Deze ene chip bevat een aantal AD 

en DA converters, Micro-controllers zijn in gebruik als digitale signaal processors (DSP's) en er 

zijn enige computers. De computers zijn: 

● een Intel 8051 : standby processor, 

● een MIPS: besturingscomputer 

● enige (één of meer) TriMedia's: signaal bewerkingen. 

De software van NXP op deze computers moet samenwerken met de software van TV fabrikanten, 

de set-makers. Ook gespecialiseerde softwarehuizen leveren software voor gepatenteerde of 

gestandaardiseerde functies. Het geheel komt uiteindelijk in uw TV thuis, tenminste als uw TV een 

NXP chip bevat. Volgens één of andere rare conventie wordt het programmeren van micro 

controllers gerekend tot “hardware” en het programmeren van de drie typen computers tot 

Pagina: 6 / 230


1 Inleiding 


“software”. Dit stuk gaat dan ook over het programmeren van die drie computers, en dan vooral 

programmeren op de computer waarbij ik betrokken was: de MIPS. 

NXP koopt het benodigde operating system voor de MIPS (Linux), en de real-time kernel voor de 

TriMedia's. Ook (cross) compilers, debuggers, en development systems worden gekocht. Zelf maakt 

ze de software voor de standby processor, het merendeel van de software op de TriMedia's, en het 

grootste deel van de drivers en hun aansturing op de MIPS. 

Als een nieuwe chip wordt ontwikkeld wordt ook het NXP aandeel van de software ontwikkeld. De 

software is deels gebaseerd op de software van de chip die daarvóór ontwikkeld werd. Dit gebeurt 

hoofdzakelijk in Bangalore. Nieuwe ontwikkelingen op het gebied van signaal bewerking vinden 

plaats in Eindhoven. Sommige drivers worden ontwikkeld in Hamburg. De TV waarop deze 

software wordt getest heet “reference design” Zo'n televisie komt vrij snel na de start van de 

software ontwikkeling beschikbaar voor testen, dus de chip is al eerder ontwikkeld. De 

ontwikkeling van chip en software vindt plaats in samenwerking met een belangrijke klant, meestal 

Consumer Electronics van Philips. Omdat de televisie standaards in de Verenigde Staten van Noord 

Amerika nogal afwijken van die in Europa worden er vaak 2 reference design televisies gemaakt. 

1.2.2 Projects en Products 

NXP zoekt een tv fabrikant om samen een nieuwe generatie televisies te ontwikkelen. NXP 

ontwikkelt de chip, en de set-maker (de klant) ontwikkelt de televisie. 

Waar NXP begint met een reference design, daar begint de klant met een standaard design. Hierin 

Pagina: 7 / 230 

Schematische voorstelling van de werkwijze 

In de eerdere projecten werd veel aandacht besteed aan design documenten en de design fase, in 

de latere projects werd hieraan minder aandacht besteed: “er is immers reeds een framework, de 

nieuwe software en de wijzigingen hoeven er alleen maar in te passen”.


1 Inleiding 


ontwikkelt de klant zijn noviteiten. De software die door de klant ontwikkeld wordt is (deels) 

gebaseerd is op de software van zijn vorige televisies. Datzelfde geldt voor het reference design: het 

is voor een deel gebaseerd op voorgaande software en hardware. Om deze designs te maken vindt er 

uitwisseling van kennis, hardware en software plaats, in het design project. NXP houdt er een 

reference board met software aan over, dat uitgangspunt is voor de verkoop aan andere klanten. De 

klant houdt er een standaard board en software aan over, die het uitgangspunt is voor zijn uit te 

brengen televisies. 

Zodra een verkoopbare televisie is gespecificeerd en een prototype beschikbaar komt, start een 

“design-in” project. In dit project wordt de software van NXP en klant passend gemaakt voor een 

TV van de klant. De NXP software is gebaseerd op het reference design, maar bevat wijzigingen die 

noodzakelijk zijn voor de TV of de stijl van de klant. 

Als het reference design klaar is, en de klant, waarmee is ontwikkeld, een afgesproken voorsprong 

heeft op zijn concurrenten, dan worden ook andere TV fabrikanten bediend met design-in projects. 

Dit vindt plaats in zowel Bangalore als Eindhoven, maar gaat naar Bangalore. In feite was ik in 

Eindhoven bijna de laatste die het licht uitdeed. 

Sommige TV fabrikanten ontwikkelen helemaal geen software. Tot voor kort bediende NXP ze met 

een complete software stack. Tegenwoordig worden de “applicatie en middleware delen” uitbesteed 

aan gespecialiseerde softwarehuizen. 

Een aantal projects zijn tegelijk aan de gang. Tussen deze projects vindt uitwisseling plaats van 

verbeteringen en nieuwe ontwikkelingen in de software. 

Meestal gebruikt de klant de chip in meerdere TV sets. Er komt dan een design-in project voor elk 

groepje TV sets dat erg op elkaar lijkt. Een groepje dat te sterk afwijkt is reden voor een ander 

design-in project. De software is dan gebaseerd op die van van een vorige design-in, of op een 

standaard design. Deze projects vonden aan de NXP kant plaats in Eindhoven maar gaan ook naar 

Bangalore. 

Deze keuze voor design-in projects en de keuze van NXP om zijn reference designs te baseren op 

voorgangers laat ons terecht vermoeden dat we te maken hebben met product familie structuren, 

compleet met huwelijken en kinderen en zo. Op een willekeurig tijdstip zijn van zo'n televisie 

familie enkele modellen in ontwikkeling, enkele modellen worden gefabriceerd, en enkele modellen 

staan in de schappen in de winkels. Voor de chip familie geldt iets soortgelijks: in een tijdsvenster 

zijn er slechts een paar typen in ontwikkeling, en worden slechts enkele typen gefabriceerd. Vaak 

zijn er enige varianten die ongeveer samen ontwikkeld worden, bijvoorbeeld een power-chip en een 

compatible eco-chip. 

Sommige klanten hanteren een fictief project: het backbone project. Dit is een voortzetting van het 

design project. Wijzigingen in een project worden, als ze algemeen bruikbaar zijn, ook gebruikt om 

de backbone software te verbeteren. Nieuwe design-in projects worden gebaseerd op de laatste 

versie van het backbone project. 

NXP gebruikt design-in projects om zijn reference design te verbeteren. Voor NXP is het reference 

model de backbone. 

Een tv project wordt geregeerd door deadlines, zoals een expositie op een beurs, een sport 

Pagina: 8 / 230


1 Inleiding 


evenement, een seizoen, en de aanvraag van een certificaat. Met een certificaat geeft een 

onafhankelijke commissie aan dat ze heeft vastgesteld dat de televisie aan een standaard voldoet. 

Vaak moet een aanvraag ruim van tevoren worden ingediend, en uitstel is afstel, dan moet opnieuw 

ruim van te voren een aanvraag worden ingediend. Elk certificaat is een stikker met logo op de 

televisie en/of de doos waar hij in zit. Na de aanvraag is er dus een deadline. 

De software “fasen” development en verification/integration zijn geen echte fasen maar lopen in 

elkaar over: op een gegeven moment werkt men niet meer aan ontwikkeling maar nog uitsluitend 

aan problemen, of aan tussentijdse wijzigingen. Dit komt omdat een nieuw project gebaseerd is op 

software van een voorgaand project. Daardoor beschikt men al zeer vroeg over een werkbaar 

geheel, en kan vanaf het begin reeds gewerkt worden aan de verification/integration fase, en wat 

betreft de verification beginnen de testers dan ook onmiddellijk met het genereren van problem 

reports. Voor design-in projects geldt dit meer dan voor (reference) design projects, waarin veel 

innovaties zitten, en waarin voor NXP naast een nieuwe TV chip ook overgangen kunnen zitten 

naar andere microcomputers, andere operating systems, andere compilers, andere debuggers 

enzovoort. De “mijlpaal” wordt dus niet bereikt als groen licht wordt gegeven voor de start van de 

integratie/verificatie fase, maar als de development fase uitgedoofd is. Deze mijlpaal wordt niet 

langer beschouwd als een go/no-go beslispunt. Zelfs is het zo dat vaak pas met een ontwikkeling 

van een nieuw feature begonnen wordt als de integratie op orde is, en dan zodra een specialist 

beschikbaar komt. 

In televisie projects zie je dat veel mijlpalen worden gedefinieerd door het overall project, dat gaat 

van idee tot de televisie bij de mensen thuis. De go / no-go mijlpalen en audits worden bepaald door 

interactie tussen markt analyse, research, hardware ontwikkeling, software ontwikkeling, 

ontwikkeling en het opzetten van (proef) fabricage lijnen, distributie, certificering, aankondiging en 

demonstratie, en dergelijke. De risico's voor een volgend traject in één of enkele van de disciplines 

zijn in principe voor een belangrijk deel afhankelijk van de opgeleverde kwaliteit van voorgaande 

trajecten in alle disciplines. De risico's worden definitief bepaald aan de vooravond van zo'n traject. 

De resultaten van audits en externe analyses moeten aangeven dat een traject gestart mag worden, 

en mogelijk ook op welke punten opleveringen in voorgaande trajecten moeten worden verbeterd. 

Uiteraard werkt men in projects het liefst met strikt opeenvolgende fasen, zodat dezelfde vooravond 

ook een “stop going / don't stop going” beslissing oplevert voor de organisatie die de voorgaande 

fase realiseerde, en voor het wel of niet vrijgeven van de mensen en middelen die daarbij gebruikt 

werden. 

De projects om een televisie te maken horen te worden gekenmerkt door een grote mate van 

beheersing van het hele proces. Op elk moment moet duidelijk zijn wat er bereikt is en wat er nog 

moet gebeuren. Onduidelijkheden in het ontwerp mogen eigenlijk niet voorkomen, daar zijn de 

research projects voor. Tegenvallers kunnen gemakkelijk uitgroeien tot een ramp. Vooraf moet er al 

een gedetailleerd inzicht zijn, wat het product behelst dat men maakt, welke resources er nodig zijn 

om het project te realiseren, en welke resources voorhanden zijn. Gedurende het project wordt 

dagelijks de voortgang gecontroleerd van alle werkopdrachten: hoe staat het met de analyse, de 

programmering, de verificatie? Er wordt bijgehouden welke tests gepasseerd zijn, welke nog niet 

kunnen worden gedaan, en welke een fout resultaat opleveren. In een project worden geregeld 

audits gehouden met lange checklists, om te bepalen of een mijlpaal is bereikt. 

Hiermee alleen lukt het niet om tijdig een goede kwaliteit televisie af te leveren. De ene keer is er 

sprake van een “Jantje van Leiden” in de eerdere stadia van het project, de andere keer moet de 

Pagina: 9 / 230


1 Inleiding 


televisie in de schappen staan voor een wereldkampioenschap, en zo is er altijd wel wat. Een project 

wordt dan ook vaak gerealiseerd door de tomeloze inzet en het overwerk van de medewerkers. 

1.2.3 De teams 

De teams die deze projects bemannen zijn gestructureerd volgens specialismen. Binnen NXP 

kennen we zoal: 

● Operating System en standby processor. 

● Frontend 

● Decoding 

● Video bewerking. 

● Audio 

● Performance 

Al naar gelang de behoefte, of de smaak van de teamleider zijn er veel subteams met weinig 

specialismen per subteam, of een weinig gestructureerd team met veel specialismen binnen het 

team. Ook zijn er design-in teams die werken voor een enkele klant (account gericht), en teams die 

(successievelijk) werken voor meerdere klanten. 

Van oudsher was er in televisies de hardware die het werk deed, en de software die de user interface 

bediende en de hardware aanstuurde. Met de digitale TV ontstaat er ook software die het werk doet: 

Video en audio bewerking. De specialisten die deze software maken zitten in een ander team dan de 

andere specialisten die zich bezighouden met besturing en drivers. Ze worden meer ingezet in 

ontwikkeling en reference design projects en minder in design-in. 

Iemand die nieuw in het televisie vak begint krijgt verantwoordelijkheid voor een deel van de 

software, bijvoorbeeld de tuner software. Hij of zij wordt dan al snel specialist. Werknemers van 

NXP volgen een ontwikkelingsplan, waarbij ze ook op andere delen en in andere teams worden 

ingezet zodat ze na een tijdje generalist worden. Inhuurkrachten volgen geen plan maar worden al 

naar gelang de behoefte na een tijdje ingezet op andere delen van de software. Sommigen worden 

zo generalist, anderen beheersen na een tijdje één of meerdere specialismen. Beide, medewerker en 

inhuurkracht, wordt een TV cursus aangeboden om meer algemeen inzetbaar te zijn. 

Teams met specialisten zijn van nature wat groter dan teams met generalisten, omdat er voldoende 

Pagina: 10 / 230 

schematic matrix organization


1 Inleiding 


dekking in TV kennis moet zijn in een project. De wat grotere teams worden ingezet op design 

projects of op veel design-in projects tegelijk. Kleinere teams worden ingezet op enkele projects 

tegelijk, bijvoorbeeld op OEM design-in projects, waarin ze in een rap tempo het éne na het andere 

project realiseren. Indien het design of design-in project veel moet vernieuwen, dan structureert 

men het team meestal volgens specialisme. 

Sommige generalisten worden factotum, en zijn niet vast aan een team verbonden, maar worden 

ingezet daar waar de druk het hoogst is. Sommige specialisten worden goeroe en worden daar 

ingezet waar hun kennis het meest nodig is. 

Vaak is een team in een project geografisch gescheiden van de anderen. Soms worden teams bij 

elkaar gebracht in één gebouw, we spreken dan van een one-roof project. De teams van de klant en 

die van NXP blijven vaak gescheiden, maar er vinden wel detacheringen plaats, ter bevordering van 

de communicatie. Soms maar niet vaak is er een one-roof team van een klant en NXP. De spreiding 

van teams van NXP en klant over de wereld leiden verder tot veel telefonisch vergaderen, zowel 

reguliere meetings, als ad hoc vergaderingen vinden telefonisch plaats. 

1.2.4 Het werk 

Gedurende de development activiteiten van de software werken de ontwikkelaars, testers en 

integrators planmatig. Software wordt (her)ontwikkeld en geverifieerd met reviews en tests volgens 

plan door testers en ontwikkelaars. De nadruk bij het testen ligt bij component en package tests. 

Reviews worden gehouden voor documenten, c files, test scripts en zo. 

Tijdens de verificatie en integratie fase worden de ontwikkelaars gestuurd door problem reports, 

testers volgen deels een integratie test plan, waarbij de nadruk komt te liggen bij product tests en 

tests van lagen. Verder verifiëren ze opgeloste problems, met name in baseline tests. Integrators 

brengen een nieuwe baseline uit per vastgestelde periode en incorporeren baseline van andere teams 

liefst éénmaal in dezelfde periode. In de laatste fase van het integratie traject, de maturing phase, 

worden de software wijzigingen van NXP per opgelost problem doorgegeven aan andere teams. 

Regelmatig worden nieuwe baselines van de eigen software verstuurd naar andere design groepen: 

werk van de build manager, uiteraard na een forse baseline test: werk van een tester, en voorzien 

van een baseline report: werk voor de integrator. Regelmatig worden nieuwe baselines van de 

software van andere teams in het project in ontvangst genomen. Ook dit is werk van de build 

manager. Zo'n nieuwe baseline moet ook in gebruik worden genomen: werk voor de integrator. 

Meestal worden baselines eens per twee weken uitgegeven, soms wekelijks of maandelijks, 

afhankelijk van de project-fase en de afspraken. Meestal duurt het enkele dagen voordat een nieuwe 

baseline door een team in gebruik wordt genomen, soms duurt het langer, en soms wordt een 

baseline overgeslagen. 

Binnen NXP sprak men over releases waar ik spreek over baselines. In software configuration 

management wordt een snapshot dat een naam heeft gekregen, en waarvoor kwaliteitseisen zijn 

gerealiseerd, over het algemeen baseline genoemd. Releases zijn –,vind ik –, gerelateerd aan 

eindproducten, die voor gebruik beschikbaar zijn gesteld aan eindgebruikers, en soms voor testen 

door eindgebruikers zoals alfa en bèta releases . 

Pagina: 11 / 230


1 Inleiding 


In het plaatje van het baseline schema is te zien dat er nog patches moeten worden ontwikkeld 

nadat een baseline is uitgebracht. Dat is eigenlijk een zwakte bod, het had voorkomen moeten 

worden. 

Zo'n baseline schema eist wel een zekere robuustheid van de software. Baseline D van package Cup 

Pagina: 12 / 230 

Baseline schema


1 Inleiding 


moet compatibel zijn met baseline T-1 en T van package Saucer, en met de ontwikkeling van 

package Saucer tot baseline T+1 en verder. Baseline T van package Saucer moet compatibel zijn 

met baseline D-1 en D van package Cup en met de ontwikkeling van package Cup tot baseline D+1 

en verder. Eventueel kunnen in de nadagen van een baseline “ baseline supplements” (patches) 

gebruikt worden om compatibel te blijven. 

Het getoonde baseline schema is echt een schematische voorstelling van zaken, in de praktijk komt 

het voor dat een team wel eens een baseline overslaat van een geabonneerd package. 

Bij parallel lopende projects worden vaak wijzigingen uitgewisseld. Soms gebeurt dit periodiek. 

Hierbij is de integrator betrokken, vaak samen met ontwikkelaars. In ieder geval is er uitwisseling 

tussen backbone en design-in projects, dit geldt voor de backbone van de klant, en die van NXP. 

Naast het werken aan de voortgang is er nog het terugkerende routinewerk: dagelijks ('s nachts 

vooral) wordt vrijgegeven software van de ontwikkelaars ingelijfd in de team software. Voordat dat 

gebeurt vindt eerst een build en een regressie test plaats. Dit is natuurlijk alleen routinewerk als de 

build en de test goed verlopen, anders moet er ook uitgezocht worden welke software fout is, dat 

gebeurt vooral de volgende morgen. Betrokken hierbij zijn de build manager en een tester, 

eventueel bijgestaan door een software engineer. 

Software moet vaak geanalyseerd en getest worden. Hiervoor is veel hardware nodig in de vorm 

van televisies, audio/video generators, dvd players, antenne pluggen met daarachter een netwerk 

aan tv zenders, meet apparatuur, en dergelijke. Het onderhoud van dit alles is het werk van de 

hardware specialisten. 

Voor planning en tracking van alle voorgaande activiteiten zorgt de change manager. Zij/hij werkt 

nauw samen met de change managers van de andere teams, en met die van het overall project. 

1.2.5 Enige slotopmerkingen 

Een design project heeft een relatief lange software development fase en een design-in project een 

relatief korte, tenminste wat betreft de NXP bijdrage. 

Marktontwikkelingen die niet voorzien zijn, tijdens het ontwerp van de chip, worden meestal 

opgelost door de klant die de elektronica uitbreidt met extra chips. Aan de voorkant van het signaal 

pad is dit in 2002 een HDMI chip geweest en in 2007 een MPEG4 chip. Aan de achterkant waar het 

beeldscherm aangestuurd wordt zijn dit in 2003 chips geweest voor scaling en natural motion bij 

grote plasma schermen, of grote LCD schermen. Recent (2008) heeft NXP een nieuwe ontwikkeling 

op het gebied van video nabewerking gestart op een afzonderlijke chip met een drietal TriMedia 

processors. Deze chip kan met de TV chip samenwerken, maar de TV chip kan ook standalone 

werken. De nieuw ontwikkelde chip kan ook zonder TV chip geleverd worden als backend van 

concurrerende oplossingen. 

In de tijd dat ik bij NXP werkte bleek dat een chip zeer snel veroudert Na een jaar design-in is er 

niemand meer die de chip nog wil. HDTV “ready” is opgevolgd door “Full HDTV”, één HDMI 

ingang moeten er vier zijn, internet aansluiting en DLNA zijn een vereiste, de beeldbewerking lijkt 

primitief vergeleken met de nieuwe algoritmen, de “punt” die over een LCD scherm raast moet niet 

Pagina: 13 / 230


1 Inleiding 


alleen het kristal openen dat hij passeert, maar ook het backlight regelen (dit is een vereenvoudigde 

voorstelling van zaken), enzovoort. Men zoekt naar een kortere doorlooptijd van design projects. 

Want nu zorgt de tijd die nodig is voor software ontwikkeling ervoor dat de omzet van de chip 

beperkt is. Ook zoekt men naar verkorting en capaciteit vermindering van design-in projects, zodat 

meer klanten in korte tijd geholpen kunnen worden. Toch gaan de herstructureringen van de 

software die hiertoe moeten leiden traag, omdat de focus ligt op het verkopen van wat men heeft. 

De investering in de software aan het begin van de eeuw, die de basis vormt van de huidige (2008) 

software stack is misschien nog niet genoeg terugverdiend. 

De eerste digitale televisies waren een succes waarmee Philips een voorsprong nam op de 

concurrentie: de televisies van de concurrentie bleven in de schappen. Bij de overgang van HDTV 

ready naar Full HDTV liet Philips zich verrassen door de concurrentie. We hadden geen 

onmiddellijk antwoord en onze televisies bleven onverkocht. 

Veel DSP's zijn specialistische digitale signaal processors die werken met een “ingebakken” 

programma. Ze delen geen geheugen met de andere processors, en voor een nieuw programma is 

een speciale loader nodig. Ze gebruiken specialistische i/o devices, bijvoorbeeld speciale AD of DA 

converters. Na het “inbakken” is er feitelijk sprake van hardware. In de tv's waarbij ik betrokken 

was werden ze bijvoorbeeld gebruikt bij het digitaliseren en decoderen van de oude analoge audio 

en video signalen naar het interne formaat. Ze zijn wel onderdeel van de éne televisie chip. 

TriMedia's zijn general purpose signaal processors met geheugen waarin steeds opnieuw software 

geladen kan worden vanuit de MIPS. Deze flexibiliteit maakt het volgende mogelijk: 

Het bewerken van tv signalen behoort tot het competentie gebied van zowel set-makers als chipmakers. 

Allebei willen ze software ontwikkelen voor signaal bewerking. Dit is software in de 

TriMedia laag, “achter”de API (application interface). De samenhang die voor deze software 

nodig is wordt bereikt met een gemeenschappelijk project van NXP en een belangrijke tv 

fabrikant: het design project. 

Er is een tendens om de development fase te verwaarlozen en alle wijzigingen te realiseren middels 

problem reports. Persoonlijk ben ik daartegen. In mijn beschrijvingen ga ik dan ook uit van 

development activiteiten. Halstead gaf een definities voor complexiteit, zoals lenght, volume, 

difficulty effort en dergelijke. Mijns inziens kun je de complexiteit in een development inspanning 

terugdringen, en kan die alleen maar toenemen in de verificatie manier van werken. Zelf ben ik er 

voorstander van dat systematisch in nieuwe projects een onderdeel van de software opnieuw wordt 

gestructureerd. Natuurlijk moet dat wel met design en development activiteiten gebeuren. Je zou dit 

kunnen verwoorden door te stellen dat geen line of code ouder mag zijn dan 6 tot 10 jaar. 

Overigens, voor nieuwe features is development nodig, je kunt doorgaans niet uitgaan van een 

“hello world” programma om vandaar uit met problem reports het feature te realiseren. 

Waardoor wordt deze tendens om meteen vol de integratie/verificatie fase in te gaan gevoed? 

● Met problem reports kunnen programmeurs in paren of alleen, onafhankelijk van de anderen 

werken, bij grotere wijzigingen moet er meer worden samengewerkt. 

Bij grote wijzigingen bijvoorbeeld, kan de software verdeeld worden over de programmeurs, 

die dus ieder hun eigen onderdeel bijhouden. Wijzigingen moeten gesplitst worden, zodat 

meerdere specialisten een deel krijgen, die wijzigingen zijn niet zonder meer onafhankelijk 

te integreren. Daarentegen bij kleine wijzigingen kunnen de wijzigingen uitgedeeld worden 

Pagina: 14 / 230


1 Inleiding 


aan de programmeurs, die ieder voor zich dan alle benodigde software wijzigen, en 

onafhankelijk integreren. 

● Test-items in de integratie fase testen of software voldoet aan de requirements voor het eindresultaat. 

Test-items in de development fase testen of een development stadium bereikt is. 

Deze test-items kunnen zeer omvangrijk worden, en zijn afhankelijk van voortschrijdende 

wijzigingen in het eisen pakket. Testers vinden dat ze wegwerp tests maken, die verder nooit 

meer bruikbaar zijn. Als je een ontwikkelingsgang wilt volgen zodanig dat de software in 

elk stadium getest kan worden met tests die een uittreksel zijn van tests uit de verificatie 

fase, dan vergt dat nogal wat van die ontwikkelingsgang: de software uit het begin moet 

compatibel zijn met de uiteindelijke software. Met een test-plan in de integratie fase is een 

overzichtelijke voortgang zichtbaar van items die nog niet kunnen worden getest, items die 

fout zijn, en items die correct zijn. Fout en correct is ten opzichte van de requirements voor 

het eindproduct. Testers maken in de integratie fase gebruik van herbruikbare tests, want alle 

televisies lijken op elkaar. 

Een voorbeeld uit begin jaren negentig van een ontwikkelingsgang die waarschijnlijk niet 

volledig de compatibele reeks stadia oplevert die testers waarderen: In een MS-DOS 

applicatie gebruik je eerst een interface die gebaseerd is op een tweedimensionale tekst 

omgeving (de voorlopige, geïmproviseerde oplossing), en later als de functionaliteit bereikt 

is ga je over op een grafische interface. 

Ooit heb ik geleerd wat een Pert network is, en hoe een Gantt chart eruitziet. Bij de ene staan de 

activiteiten in de knooppunten en bij de andere in horizontale balken langs een tijdlijn. Bij beiden 

zijn de afhankelijkheden van de activiteiten weergegeven met pijlen. Ik meen mij te herinneren dat 

er ooit ook nog een soort geïnverteerde Pert chart was, met de activiteiten in de pijlen en de 

afhankelijkheden in de knooppunten, maar in Wikipedia vond ik slechts de opmerking dat dit een 

AOA (activity on arrow) schema was. In de vele kleine projects waaraan ik heb deelgenomen (één 

tot vier mensen voor de software) heb ik serieus geprobeerd volgens zo'n plan te werken, en altijd 

bleek weer dat de vooraf bedachte afhankelijkheid eigenlijk helemaal niet gold. Het was misschien 

handig als module A klaar was voor B, maar als dat niet zo uitpakte, dan improviseerde je wat, en 

kon je B gebruiken of testen zonder A. Hierin lijkt software werkelijk soft te zijn, harde volgorde 

doet er eigenlijk niet zoveel toe. 

Ik dacht dat het aan mij lag, dat de afhankelijkheden en werk indeling constant veranderden, als het 

ging om ontwikkelafhankelijkheden van onderdelen. Ik dacht dat ik mij teveel liet leiden door de 

inspiratie en de waan van de dag, in plaats van te werken volgens het plan. Ik dacht dat anderen er 

geen last van hadden. 

Het testen van televisie software, en zelfs het ontwikkelen ervan is voor een groot deel (in ieder 

geval het aandeel van NXP op de MIPS) afhankelijk van de hardware (of van de software in de 

TriMedia). Ieder die betrokken is bij embedded software ontwikkeling weet dat en voelt dat: je kunt 

een driver misschien wel testen zonder hardware, maar dat is niet echt, en heeft niet veel waarde. 

Je moet de software testen op de hardware, punt! In de software-werkplaats werken vakmensen die 

specificaties leuk vinden, maar liefst zo snel mogelijk willen werken aan de hand van 

waarnemingen. Trouwens een GUI applicatie maak en test je ook niet zonder grafische kaart en 

window manager, dus zuiver op specificaties. 

Toen we de software voor de digitale televisies ontwikkelden, hebben we het serieus geprobeerd. We 

Pagina: 15 / 230


1 Inleiding 


creëerden voor een driver een “test skeleton” waarin we de driver testen op de aangestuurde 

hardware. Iedere driver kreeg zijn eigen skeleton. De hardware, wat die doet is afhankelijk van de 

manier waarop hij wordt aangestuurd door de driver, en van het signaal dat hij verwerkt. Als je 

software test, kijk of luister je onder anderen naar wat de hardware component met het signaal 

doet, gegeven de manier waarop je hem aanstuurt. Het signaal komt van een input bijvoorbeeld een 

antenne en eindigt in een output, bijvoorbeeld een scherm, en passeert een aantal hardware en 

TriMedia componenten. De manier waarop de belendende componenten moesten worden ingesteld, 

dat bleek niet erg stabiel te zijn. Voordat je een bestaand skeleton kon gebruiken moest je het eerst 

aanpassen aan de laatste toestand van de software. Naarmate de tijd vorderde kon je meer verfijnd 

testen van meer input pluggen, naar meer outputs, en met meer nuances in de signalen, en moest je 

je test-doelen bijstellen. Skeletons bevatten gedurende langere tijd geïmproviseerde software van 

belendende componenten. 

Later zijn deze skeletons afgeschaft. Nu wordt uitsluitend getest met “het product” of met een 

“platform harness”. Dit harness wordt ook gebruikt als een specifieke driver moet worden getest. 

Maar dat van die verfijning en uitbreiding, naarmate de tijd voortschrijdt, dat is gebleven, en 

beïnvloedt de testscripts. 

Ik merkte dat ik niet alleen was. Het is dus niet: “Ik dacht dat anderen er geen last van hadden ” 

maar: “Wij denken dat de anderen er geen last van hebben”. 

“Waarom zijn design-in projects nodig? Kan dit niet opgelost worden met configuratie bestanden en 

hardware herkenning?” 

● Nu in de eerste plaats is een televisie van zo'n design-in project een unieke gelegenheid om 

de combinatie van software met de bijbehorende configuratie file en de bijbehorende 

hardware te testen. Deze gelegenheid was er niet eerder, want de televisie was nog niet 

ontworpen of gemaakt. Het testen van de software van een TV heeft al een doorlooptijd van 

een aantal weken. De fouten die er uit komen moeten dan nog opgelost worden, waarna de 

tests opnieuw moeten worden uitgevoerd. Het is bekend dat de introductie van software in 

en nieuwe gebruikersgroep begint met de ontdekking van een aantal problemen en fouten. 

Dit geldt blijkbaar ook voor de introductie van software in een nieuwe televisie. Ik meen dat 

dit wel eens verwoord is als volgt: hoe meer gebruikers er zijn hoe meer fouten er worden 

gevonden. Waarschijnlijk geldt dit meer algemeen voor omgevingen waarin software moet 

functioneren, en hoeven meer omgevingen niet per se meer gebruikers te zijn. 

● In de tweede plaats is het ontwerpen van een televisie of een televisie lijn een creatief proces 

waarmee men vriend en vijand probeert te verrassen. Als er alleen een configuratie bestand 

moet worden gemaakt, omdat de diversity adequaat is dan is in feite het verrassen mislukt: 

de configuratie was min of meer voorzien. Dat is niet de bedoeling. 

● Tenslotte is het zo, dat de 'universele” one chip TV die door NXP gemaakt is niet altijd 

rekening houdt met de specifieke eisen van een door een klant te maken TV set, ook al was 

bekend dat de specifieke eisen er waren. Integratie van de chip in zo'n set is dan niet triviaal, 

maar mogelijk wel de beste manier om de set te maken. Dus een design-in project is nodig. 

Het projectmatig samenwerken betekent dat het ideaal van component software, zoals aangegeven 

door Clemens Szyperski in het boek “Component Software” niet bereikt is: er is geen volledig 

“Independent Deployment”. 

In de tijd dat ik bij NXP werkte was het geen usance om eindgebruikers een upgrade van de 

Pagina: 16 / 230


1 Inleiding 


software te sturen. Als de televisie op de markt kwam dan moest de software klaar en goed zijn. Een 

upgrade was in feite een nederlaag. Naarmate “independent deployment” zijn intrede doet zal een 

eindgebruiker merken dat upgrades normaal worden: het op de markt komen van een tv betekent 

niet langer dat deze uit ontwikkeld is, althans op software niveau kunnen componenten worden 

opgevolgd door andere. 

Voor set makers betekent dit dat nieuwe software ontwikkelingen niet langer alles bepalend zijn 

voor de time to market van een televisie: men kan de tv leveren met bestaande software, en later 

upgrades sturen. Voor de software ontwikkeling betekent dit dat men rekening moet houden met 

adaptive maintenance van alle software in alle design-in (inmiddels maintenance) projects. Het 

aantal design-in projects dat tegelijk onderhanden is zal in zo'n situatie drastisch toenemen. Om een 

en ander met dezelfde mensen te realiseren zal de software die ontwikkeld en getest wordt aan de 

hand van algemeen geldende specificaties moeten toenemen, en de software die specifiek is voor 

een bepaalde hardware en daarop getest moet worden, die software en de tests ervan zullen beter 

afgebakend moeten worden. Een subproject dat een package ontwikkelt moet dit dus kunnen doen 

voor meerdere televisies dus voor meerdere master projects. 

Voor NXP geldt bovendien dat zijn software ontdaan moet worden van klant specifieke oplossingen. 

Met digitale televisie werd begonnen –, samen met Philips CE –, nog voordat al die afbakeningen 

definitief en hard waren gespecificeerd. 

Waarschijnlijk maakt dat de samenwerkingsprojecten uit die tijd toch wat uniek. Voor tv software 

programmeurs bij set-makers is het toch een beetje een cultuur omslag als er bijna uitsluitend tegen 

specificaties getest en ontwikkeld moet worden, zonder de hardware zeg maar, want die leidt dan 

maar af. Maar voor het NXP aandeel geldt dat NXP zich juist terugtrekt op de hardware software 

interface. 

“Component Software. Beyond Object-Oriented Programming” Clemens Szyperski (ACM / Addison 

Wesley: ISBN 0-201-17888-5). 

Televisie mensen zijn gewend aan systemen met een “kloppend hart”. Een televisie is onderworpen 

aan het strenge regime van 50 of 60 beelden per seconde. Een beeld moet volmaakt op het scherm 

staan voordat het volgende beeld aan de beurt is, anders krijg je “macro blokken” of andere 

storingen. Zo richten ze ook hun projects in: dagelijks wordt de software bijgehouden, periodiek 

(wekelijks, 2 wekelijks, maandelijks afhankelijk van de project-fase en het project) komt er een 

nieuwe baseline. Hun projects kenmerken zich door een “kloppend hart”. Dit creëert dagelijkse en 

periodieke deadlines waarin de dingen moeten gebeuren. Veel handelingen zijn tijdrovend, en 

worden onder tijdsdruk wel eens achterwege gelaten, hierin zijn televisie mensen minder strikt in 

hun projects dan in hun tv's. 

“Waarom wordt er eigenlijk zoveel voortgang gecontroleerd? Blijkbaar gaat men er van uit dat je 

als manager kunt ingrijpen bij vertragingen, maar kan dat wel? Er geldt toch de regel dat meer 

mensen op een te laat project de zaak alleen maar meer vertragen?” 

De meeste voortgangsproblemen hebben geen crisisachtig karakter en worden opgelost doordat 

teamleden elkaar helpen, onderling het werk herverdelen, en (nog) wat meer uren maken. Ook kan 

men binnen een team vrij probleemloos met capaciteiten schuiven van het éne project naar het 

andere. 

Behalve dat hij wel heel erg een eigen leven is gaan leiden, en iedereen er meteen naar wijst als het 

management ingrijpt, is er nog iets grappigs aan die oude wet (in 1975 gepubliceerd geloof ik). Om 

hem te controleren zou het project zich moeten splitsen in een project dat op de oude manier 

doormoddert, en een project waar nieuw bloed leidt tot herbezinning (dat kost tijd) en misschien tot 

Pagina: 17 / 230


1 Inleiding 


nieuw elan (dat spaart tijd, mits het lukt). Het enige wat je kunt meten is één van de voortgangen, 

want andere hebben zich niet voorgedaan. Of de wet in een specifieke situatie mag worden 

overtreden is mogelijk een kwestie van geloof, inzicht en ervaring. 

In ieder geval zijn de eerder genoemde factotums en goeroes enkele malen met succes ingezet in 

crisisachtige situaties. Het motto van de leiding was: “be prepared”. Ze waren erop voorbereid dat 

plannen kunnen mislukken, en dat bleek sterker dan de wet van Brooks. Eigenlijk is het natuurlijk 

ook de aard van het bedrijf en het product waardoor de wet niet per se geldt, en mensen 

gemakkelijk kunnen verhuizen van het éne project naar het andere, en van het ene team naar het 

andere, al is het nooit helemaal naadloos. 

Let wel: bij het toevoegen van een factotum aan een project gaat het primair om de extra 

“man-months”, dus het is een echte lange neus tegen de wet. Er lopen dan extra mensen in paren of 

individueel in de tredmolen: problem report van de stapel halen, fout analyseren en verbeteren, 

testen, regressie test uitvoeren, inchecken, problem report van de stapel halen, ... Je helpt elkaar 

waar nodig, maar dat neemt niet excessief toe met nog meer mensen. Behalve de eerste paar dagen, 

waarin de ervaren nieuwkomers worden bijgepraat, gaat alles zijn gewone gang. Zelfs minder 

ervaren mensen zijn wel eens ingezet, onder leiding van de project architect, en met de afspraak dat 

ze vooral steun zouden zoeken bij elkaar, en dat ze vooral werk van de stapel zouden halen dat tot 

hun specialiteiten behoort. Of ze de project-duur significant hebben verkort is mij niet bekend, 

hoogstwaarschijnlijk hebben ze de duur niet verlengd. Qua methode: “baat het niet, het schaadt ook 

niet”. Dat geldt in ieder geval voor de doorlooptijd. 

Er zijn veel boeken over team building, en ook over crisis management, en ik heb ooit heel vroeger 

een enkele gelezen. Eigenlijk weet ik niet echt hoe je een team bemant en de menselijke 

samenstelling onderhoudt, of hoe je professioneel ingrijpt als zich een crisis voordoet. De boeken 

waarvan ik mij nog maar nauwelijks de details herinner: 

“The Mythical Man-Month”. Frederick P. Brooks, Jr. (Addison-Wesley: ISBN 0-201-00650-2)) 

“The Psychology of Computer Programming”. Gerald M. Weinberg (Dorset House Publishing: 

ISBN: 0-932633-42-0 384) 

Soms moet je als manager wel ingrijpen. 

Zelf ben ik samen met een collega medio jaren tachtig wel eens ingezet in een klein te laat project, 

als software reviewer van software die geschreven was in een mij onbekende script taal. Het ging 

meen ik om een implementatie van een EDI systeem betreffende de goederen stroom (orders, 

leveringen, facturen en dergelijke). Het betrof een in-house project van TASS voor het rekencentrum 

van Philips in Eindhoven. 

Het IBM mainframe waarop getest moest worden was pas laat beschikbaar gekomen, waardoor er 

een soort big bang situatie was ontstaan: alle software werd geïntegreerd getest. Toen mijn collega 

en ik begonnen was testen zelfs compleet onmogelijk. Vandaar dat we werden ingezet als reviewer 

en vandaar dat het team er nogal moedeloos uitzag. 

Eén fout is ontdekt door iemand die zijn software nakeek om een vraag van mij te beantwoorden 

toen ik mij inwerkte, sommige fouten vond men zonder onze inbreng, andere met een van ons als 

praatpaal, en een enkele fout vonden we zelfstandig als reviewers. Na een week of twee hadden we 

met elkaar de spook-verschijnselen in de software verklaard en verbeterd, en toen was het project 

ook zo goed als klaar. 

Uitspraak achteraf van de staf: “Brook's vuistregel is er om overtreden te worden, maar liefst wel 

Pagina: 18 / 230


1 Inleiding 


intelligent”. 

OK, ik zal wat meer details geven. De meeste fouten waren peanuts. Er was maar één systematische 

fout verantwoordelijk voor de spook-effecten die testen onmogelijk maakten. Deze fout kon 

woekeren omdat er tijdenlang geen mainframe beschikbaar was voor testen, en misschien ook 

omdat het team bij TASS zat, en niemand van de klant over een schouder meekeek. 

De teamleden hadden het taaltje geleerd van voorbeelden, van elkaar, en van iemand bij de klant, 

waar de taal inmiddels een beetje ingeburgerd was. De scripttaal en de interpreter waren nogal in 

elkaar geflanst. Een procedure call was geïmplementeerd zonder call stack: er werd maar één 

return adres onthouden. Bij elke call opdracht, en alleen bij elke call opdracht, werd het returnadres 

register bijgewerkt en bij elke return opdracht vond een goto plaats naar het onthouden 

adres. Wie denkt nou aan zoiets als je van huis uit C of Pascal programmeur bent op een VAX/VMS 

systeem of op een Unix mini: de Philips P800. 

De systeembeheerders, werkvoorbereiders en operators in het rekencentrum waren gewend aan 

JCL, aan allerlei hen opgedrongen configuratie files, en aan de ongein die applicatie 

programmeurs op de laatste project dag nog even voor ze uitvinden, zoals de beruchte datum 

ponskaart. (Nou ben ik behoorlijk aan het chargeren, dat gebeurt lang niet altijd.) Ze vonden zo'n 

regel of interpreter niets bijzonders, en het ontbreken van validatie heel normaal. Deze catastrofe 

had de klant niet kunnen voorzien. 

Ik moest of wilde mij inwerken zonder het team teveel te belasten, dus ik leerde het taaltje uit een 

boekje en geloofde mijn ogen niet toen ik las dat je binnen een subprocedure geen procedure call 

mocht uitvoeren. Zo was ik, denk ik, de eerste die de fout-oorzaak ontdekte. 

Dus ik wist: “je moet wel wat geluk hebben, een ander was je zomaar vóór geweest”. 

Achteraf gezien was het misschien niet zo rationeel, om je in te werken zonder het team te belasten. 

Iemand inwerken heeft immers op zich al een hoog review gehalte. Ook hiermee hebben we 

mogelijk geluk gehad, al had ik mij laten ringeloren door de wet van Brooks. 

In onze presentatie als reviewer toonden we aan dat de verschijnselen bij het testen het gevolg 

waren van de diepte structuur en de call beperking. Spokerij werd vervangen door logica, en het 

gedrag van de software kon tenslotte door iedereen worden nagespeeld en begrepen. Maar ook was 

onontkoombaar duidelijk dat de fundamentele structuur van de software vervangen moest worden. 

Dat bleek voor ieder bijzonder moeilijk te accepteren: het was verder een goed doordacht concept. 

De volgende dag, nadat ze een vlak gestructureerd framework hadden geadopteerd, en de taken om 

het frame in te vullen waren verdeeld, zaten ze weer neuriënd achter hun CRT scherm. Alleen de 

teamleider, die de oorspronkelijke opzet had bedacht, was nog lange tijd van slag, maar hij heeft 

zich, als ik het mij goed herinner, niet ziek gemeld. 

Vanwege dat acceptatie probleem en vanwege hun moedeloosheid geldt mogelijk: “Misschien 

waren ze er niet uitgekomen zonder nieuwe medewerkers in het team”, en had ik helemaal geen 

geluk gehad. Misschien maar goed dat de staf niet naar de wet had geluisterd. 

Pagina: 19 / 230


1 Inleiding 

1.3 De televisie als bedrijf 


Als je de televisie ontleedt, hetzij hardware hetzij software, dan vind je een componenten structuur. 

Toch herken je vaak nog een bedrijfsmodel. Er is een transformatie laag, een besturing en planning 

laag, en een laag waarin doelen geformuleerd worden (door de zapper). Het is natuurlijk wel een 

simpel model zonder een strategische component, zonder verander processen, zonder projects, en 

zonder informele gegevens. 

In de hardware zie je de TriMedia, en de DSP's die zich bezig houden met het transformatie proces, 

en de MIPS die vooral gebruikt wordt voor besturing en planning, en met een beetje goede wil zou 

je de stand-by processor, die onder meer belast is met het ontvangen van de signalen van de 

afstandsbediening, kunnen zien als de component die zich bezighoudt met de doelen. Dit laatste is 

een grapje, de stand-by processor heeft nog enkele simpele ad converters, beheert een aantal aan/uit 

poorten, (sommige van deze poorten worden gebruikt als input andere als output, soms als 

input/output), en bevat een wekker, hij is voornamelijk een ondersteunende afdeling, Het ontvangen 

opslaan en bijhouden van de bedoelingen van de zapper is een taak van de MIPS software. 

In de software is herkenbaar de software die zich bezig houdt met het transformatie proces. Dit is 

altijd TriMedia software, De besturing en planning software zelf is gesplitst in middleware en de 

drivers (AV platform laag). De driver laag draait deels op de MIPS, maar sommige hardware 

componenten worden bestuurd vanuit de TriMedia. Er is nog ondersteunende software: os 

(operating system), een API laag tussen TV software en het onderliggende operating kernel. En er 

zijn de applicaties. Op de MIPS was de kernel vroeger een gespecialiseerde real time kernel, maar 

tegenwoordig is dit Linux. De TriMedia gebruikt nog wel een specifieke real time kernel. 

Planning en besturing maakt gebruik van gegevens die door de zapper of door applicaties zijn 

verstrekt, van configuratie gegevens, van gegevens die door dealers wordt verstrekt (bijvoorbeeld 

geografische informatie) en van gegevens die afkomstig zijn van de te verwerken signalen. Deze 

laatste categorie gegevens kunnen een real time probleem geven als ze afgehandeld moeten worden 

door de MIPS software. 

Een voorbeeld hiervan is de aanwezig/afwezigheid detectie van een signaal. Bij afwezigheid moet 

meestal geen ruis maar een blanco scherm gepresenteerd worden. Als de bestuurder moet beslissen 

dan zie je even ruis op het scherm, en als dit autonoom wordt afgehandeld dan zie je geen ruis. Er is 

een enkel geval waarin het tonen van ruis functioneel wordt geacht, dan wordt niet gedelegeerd, in 

alle andere gevallen wordt wel gedelegeerd. 

Een ander voorbeeld is “fast blanking” Een video recorder stuurt via een scart plug een CVBS 

signaal naar de TV, maar als de gebruiker de video recorder instelt dan wordt gebruik gemaakt van 

de TV voor de menu's van de video recorder (OSD: on screen display), en wordt niet alleen het 

CVBS signaal gestuurd maar ook een RGB signaal met het menu. Beide signalen beslaan in 

principe het hele scherm. Er wordt een aan/uit signaal – “fast blanking” genaamd – meegestuurd om 

aan te geven waar in het RGB signaal het menu staat. De besturing software is te traag om de 

overgang te realiseren, terwijl de transformatie laag enkele pixels nodig heeft om te schakelen, 

nadat de recorder de wenselijkheid van de overgang heeft gerapporteerd. Daarom kan de 

transformatie laag deze CVBS/RGB v.v. overgang autonoom afhandelen. Er is echter ook hardware 

waarin deze faciliteit ontbreekt, en dan wordt de overgang alsnog door de besturingssoftware 

beslist. Maar nu kost een dergelijke overgang enkele frames, in plaats van één pixel. Als de zapper 

Pagina: 20 / 230


1 Inleiding 


een tv station kiest dan wordt fast blanking niet toegestaan, maar als naar de scart van een video 

recorder of dvd speler wordt gezapt dan wordt fast blanking gedelegeerd. 

Bij nieuwe hardware (of TriMedia software) kan 

de software engineer verrast worden door 

faciliteiten die opeens autonoom kunnen worden 

afgehandeld, of door faciliteiten die dat opeens 

niet meer kunnen. Iemand die UHAPI bestudeert 

zal zich soms misschien wel eens afvragen 

waarom bepaalde dingen autonoom afgehandeld 

kunnen worden door de transformatie laag. 

Meestal is er een goede reden. Daarna kun je je 

dan afvragen waarom er een mogelijkheid 

geboden wordt om dingen niet autonoom te laten 

afhandelen, en waarom zo'n functie soms 

ontbreekt in de transformatie laag. 

UHAPI: Universal Home API. Dit is een interface 

verzameling die gedefinieerd wordt door het 

UHAPI forum. Meer details zijn te vinden via 

Wikipedia (Engels) UHAPI. 

Met de komst van de digitale televisie komt er 

meer nadruk op te liggen op de tv als een 

verzameling applicaties. We hadden reeds een 

menu structuur, teletekst, een automatische 

programmagids, misschien een faciliteit voor 

automatisch opnemen, en dergelijke. Met de 

komst van digitale tv komt er ook interactieve tv: 

MHEG en MHP. Daarnaast zijn er multimedia en 

internet toepassingen, variërend van fotoalbum, 

tot beeldtelefoon, al dan niet volgens de DLNA 

standaards. Er zijn nieuwe methoden van 

copyright bescherming zoals DHCP, er zijn 

Fast blanking 

methoden van pay-tv met behulp van een CI 

(common interface). PIP, menu's en teletekst zijn 

uitgegroeid en behoeven een volwaardige window manager, gefaciliteerd door een sophisticated 

scaler/mixer. Het pure streaming transformatie systeem wordt een steeds kleiner deel van de 

televisie. Naast het “bedrijf” bevat de televisie zo ook een aantal “klanten” van het bedrijf: de 

applicaties. 

De besturing van het audio video platform vindt uiteindelijk plaats door registers te zetten, en 

registers te lezen. Er is een centrale database waarin voor veel situaties de register standen staan. De 

beheer software gaat uit van een aantal standaard instellingen,en weet wat de afwijking is van de 

standaard en bepaalt daarmee de register inhoud. Bijvoorbeeld, stel er zijn 2 ingangen voor analoog 

geluid. Via enige analoge elektronica bereikt dit signaal de omzetter naar een digitaal signaal. De 

analoge componenten hebben eigenschappen binnen toleranties. Als een tv gemaakt wordt, en 

mogelijk naderhand tijdens onderhoud, wordt door metingen vastgesteld wat de afwijking is van 

Pagina: 21 / 230


1 Inleiding 


een norm. Dat wordt gecompenseerd met afwijkende register waarden. Een gebruiker die het 

geluidsvolume bijstelt vindt dat dat lineair gebeurt, maar de expert weet hoe de register settings 

moeten worden bijgesteld, gegeven de afwijkingen van de elektronica. Tuning is ook nodig om 

ontwerp karakteristieken te compenseren, zodat een analoog of digitaal signaal hetzelfde overkomt, 

of het nu van de tuner, MPEG speler, HDMI of scart afkomt, en hoe het bewerkingstraject er ook 

uitziet. Het vindt plaats op alle ins en outs. Tuning vindt plaats door berekening, meten in de test en 

integratie fase en voor de toleranties tijdens de fabricage of tijdens onderhoud. 

Om optimale beeld kwaliteit te waarborgen moet er regelmatig bijgestuurd worden. De stuurmanskunst 

is onderdeel van de platform besturing. Het bijsturen hoeft niet slechts te zijn gebaseerd op 

metingen van de signalen. Temperatuur metingen in de televisie, en het meten van licht en geluid in 

de omgeving is ook mogelijk. 

Het connection management, dat reageert op zappen en signalen die wegvallen, of die juist 

beginnen, regelt het opzetten van signaal routes. 

Een deel van het power management: het planmatig aanschakelen en uitschakelen van een televisie 

is voor een deel de platform besturing. 

Schematisch overzicht van het transformatie proces: een typisch Europese televisie 

Opmerkingen bij “Schematisch overzicht van het transformatie proces: Europese televisie”: 

Pagina: 22 / 230 

● De switches zijn gemerkt met een “X” het zijn “source selection switches”. 

Een output pin is altijd verbonden met hoogstens één input pin, een input 

pin kan verbonden zijn met meerdere output pinnen. De kolommen met een


1 Inleiding 


X representeren in feite een groep matrices, waarin afzonderlijk schakelbare output pinnen 

zitten. In één matrix kan iedere output pin worden verbonden met iedere input pin, maar niet 

met twee input pinnen tegelijk. 

● From file: de file is geselecteerd in het “connectivity system” en komt van het 

internet/intranet, van een USB-stick soms zelfs van een interne harddisk. 

● Sources die verbonden zijn middels scart zijn “statisch” geclusterd, maar sommige AV 

sources zijn “dynamisch” geclusterd (verbonden met diverse pluggen aan de achterkant van 

de tv).Het betreft dan soms een combinatie van YPbPr (3 pluggen type RCA), CVBS (1 plug 

type RCA), YC (1 plug type S-Video) LR (2 pluggen RCA), SPDIF (1 plug type FOSLINK ), 

maar ook combinaties met DVI en HDMI zijn mogelijk. Een source is bijvoorbeeld een DVD 

speler. De verzameling tv pluggen waarmee de dvd speler is verbonden vormen een input 

cluster die gezamenlijk de DVD speler representeren. Dit is vaak een dynamisch cluster, de 

samenstelling van de pluggen is niet voorgeprogrammeerd. 

● Een enkele source kan “inbreken” als het betreffende apparaat gaat spelen, en 

interrumpeert de main source. Het daarvoor benodigde signaal wordt door de tv 

gemonitord. Als het apparaat aanstaat dan toont de source een logo als je er naar zapt. Dit 

is meestal geen reden voor break-in. Het apparaat moet echt gaan spelen. 

● Sommige source clusters kunnen meerdere versies van een signaal tegelijkertijd aanbieden. 

Vaak wordt in zo'n situatie automatisch het digitale signaal of het signaal met de grootste 

bandbreedte (het minst gecomprimeerde signaal) geselecteerd. De niet geselecteerde 

signaal routes moeten dan vanaf source tot aan “signal selection” intact zijn zodat de 

aanwezigheid van het signaal gemonitord kan worden, dit moet in ieder geval gebeuren 

voor de route van het voorkeur signaal. 

● Sommige sources kunnen successievelijk (achtereenvolgend) meerdere soorten signaal 

aanbieden, op dezelfde pluggen. Dan wordt automatisch het juiste pad gekozen na een 

verandering. 

● Een club is in feite een groepje destinations die gezamenlijk naar dezelfde source kijkt en 

luistert. Het is geen gangbaar begrip in televisieland, maar het is evident dat clubs bestaan. 

● Encrypted canal plus club. Het “encrypted canal plus” signaal komt uit de tuner, en gaat 

naar Scart1 (destination) en zo naar de canal plus decrypt box. De “main” club kijkt en 

luistert ondertussen naar Scart1 (source) naar de audio en video signalen die uit de decrypt 

box komen. 

● In feite is de “encrypted canal plus” route open als de tuner staat ingesteld op een analoog 

station, dus ook bij niet versleutelde signalen. 

● Subwoofer club. Het Spdif output signaal komt uit de “main” club en gaat naar de homecinema 

audio set. Het subwoofer signaal komt uit de home-cinema audio set. De speakers 

van de tv vormen in deze schakeling de “subwoofer” van het surround audio systeem. Het 

lipsynchroon probleem van digitale tv's wordt door de tv opgelost: het Spdif output signaal 

is lipsynchroon met de video. Van de home cinema set en de subwoofer club wordt verder 

geen significante doorlooptijd verwacht. 

● De encrypted canal plus club, en de subwoofer club hoeven feitelijk geen source te kiezen. 

Voor die clubs ligt de source vast. 

● Naar de main club kunnen schakelen: Main window, Speakers, Headphones, Scart, Spdif, 

LR sound. 

● Naar de PIP club kunnen schakelen: PIP window, Speakers, Headphones, Scart, Spdif, LR 

sound. Wat ik PIP (picture in picture) genoemd heb kan ook een gelijkwaardig “second 

Pagina: 23 / 230


1 Inleiding 


window” in een “dual window” televisie zijn. 

● PIP window en Main window kunnen niet echt schakelen naar een club, het zijn vaste 

clubleden van hun eigen club. 

● Naar “Sound only” kunnen schakelen: Speakers, Headphones, Spdif, LR sound. Sound kan 

in principe uit elk der sources komen. Merk op: scart output doet niet mee, maar produceert 

geluid, dat hoort bij de betreffende video (uit de main, pip, of canal plus club). 

● Video route selecties zijn chip en software afhankelijk. Een voorbeeld van signalen die ieder 

een eigen route volgen: 

gewone video (1FH in het jargon) 

HD ready (2FH) 

Full HD (3FH) 

PC monitor, Game: deze moeten zonder vertraging, dus nogal onbewerkt getoond 

worden. 

● Een van de vele voorbeelden waar het schema niet exact opgaat: 

Voor Scart output kun je kiezen of een CVBS signaal wordt geleverd of een Y/C signaal. 

Maar deze keuze is er niet als het signaal afkomstig is uit de “encrypted canal plus club”, 

dan wordt altijd het CVBS signaal geleverd: 

Met nog meer details ziet het schema er nog weer anders uit. Pin 19 van de scart ontvangt 

of het CVBS of het Y (luminance) signaal. Het C (chrominance) signaal komt wel of niet op 

pin 15: dat werkt niet met een “input selection switch”, maar een “open/close switch”. 

Toen er uitsluitend zwart/wit tv's waren was er slechts het luminance signaal. Met de komst 

van kleuren tv's werd CVBS geconstrueerd zodanig dat CVBS onbewerkt te gebruiken is als 

luminance signaal in zwart/wit tv's. Het verschil tussen CVBS en Y/C output is vaak 

uitsluitend het “bij”schakelen van het aparte chrominance signaal, omdat CVBS gebruikt 

kan worden als het luminance signaal. 

Het bandbreedte voordeel van het Y/C signaal wordt natuurlijk niet geëffectueerd, als de 

source een CVBS bron is: het signaal wordt niet beter dan het is. 

● Mixing voor speakers en headphones: per afzonderlijke speaker kan er sprake zijn van 

equalizing en mixing van de oorspronkelijke (mono, stereo, surround) audio-stromen. 

Featuring en encoding gaan daarbij hand in hand. We beschouwen de DAC (digital to 

analog conversion) als encoding, de rest als featuring. 

Pagina: 24 / 230


1 Inleiding 

1.4 Televisie, de software 


Ik heb voornamelijk met Philips Consumer Electronics samengewerkt. Zowel NXP als Philips CE 

gebruiken de taal C als programmeertaal. Toen ze samen een digitale TV gingen maken bleek dat 

wel zo ongeveer de enige overeenkomst. 

1.4.1 Architectuur en component modellen 

Toen Philips Consumer Electronics en Philips Semiconductors gingen samenwerken om een 

digitale televisie te maken was de situatie als volgt: 

De software architectuur van CE wordt MG-R genoemd. Deze naam is afgeleid van het MG98 

project waarin voor het eerst een component model werd gebruikt in een Philips televisie. MG-R 

betekent MG-Revised. De Software stack van CE gebruikt al sinds MG98 uit de vorige eeuw Koala 

voor de indeling van software in “compile time” componenten, die met elkaar communiceren 

middels Koala interfaces. (documentatie is te vinden met Google: trefwoord “Koala 

Component”). 

Recente documentatie over Koala vond ik niet. Er is: “The Koala Component Model for Consumer 

Electronics Software”, Rob van Ommering, Frank van der Linden, Jeff Kramer, Jeff Magee; IEEE 

Computer, March 2000, p78-85. Er is een website waar een opensource versie wordt aangeboden. 

XT / Koala compiler. Zelf heb ik thuis stiekem het manual "The Koala Yellow pages", waarin de 

volgende zin staat: "The Koala pages have been written in July 1997. They have been updated in 

October 2000, October 2001 and September 2002." 

Koala compileert cd, dd, id, en pd files, en genereert een h file per Koala module. Soms genereert 

Koala ook c files, namelijk als voor de betreffende Koala module niet met de hand een c file is 

gemaakt waarin interface functies worden geïmplementeerd. Koala gebruikt een database waarin 

wijzigingen kunnen worden aangebracht. In een clean build wordt een nieuwe database gemaakt. In 

vervolg builds worden wijzigingen in de source files gebruikt om de database te wijzigen 

Gewijzigde input files resulteren in een gewijzigde database en van daaruit in gewijzigde h files en 

c files. De betreffende folder bevat na afloop van een Koala build niets anders dan de huidige h en c 

files. Hierdoor is duidelijk welke object files kunnen vervallen, welke blijven welke nieuw of 

opnieuw gemaakt moeten worden. Wijzigingen in een c file in de source tree, die ongeveer dezelfde 

naam heeft als de overeenkomstige h files, en die deze inlijft, bepaalt mede welke object files 

wegens wijzigingen opnieuw moeten worden gemaakt. De lijst met objects in de object folder 

bepaalt de nieuwe inhoud van de executable. Het merendeel van build: controle op gewijzigde cd, 

dd, id, en pd files, worden behandeld door Koala. Wat overblijft voor make is redelijk simpel en 

recht toe recht aan. 

NXP noemde haar architectuur DVP (digital video processing). De software van NXP (voorheen 

Philips Semiconductors) voor de TriMedia gebruikt voornamelijk IDL interfaces en “COM” 

methoden voor de RPC communicatie met de MIPS. De COM methode voorziet niet in het 

genereren van make files. Er werd gebruik gemaakt van recursive make. 

De COM methode maakt gebruik van de midl compiler. Deze compiler compileert idl files. Hij 

maakt er proxy/stub programmatuur en h files van. Proxy is het marshaling deel aan de client zijde 

en stub het marshaling deel aan de server zijde. Ik herinner mij dat de bij een interfaces of een 

component benodigde GUID (global unique identifier) in een c file wordt geplaatst. Dit laatste 

Pagina: 25 / 230


1 Inleiding 


dient om te controleren of de versies van componenten en interfaces die verondersteld worden in 

client software, of die versies aanwezig zijn, of bediend worden in de server software. Ook wordt de 

midl compiler gebruikt om een registry samen te stellen. UHAPI interfaces worden met behulp van 

RPC doorgegeven aan de TriMedia, en aan de drivers van de DSP's. 

COM wordt gebruikt zonder ActiveX of tekst interfaces voor script talen. Zie Wikipedia, en 

Google. Trefwoorden “Microsoft COM”, “midl compiler” en zo. 

De architectuur van de geïntegreerde MG-R/DVP software wordt NHSW genoemd: Nexperia Home 

SoftWare. He betreffende gedachtegoed wordt beheerd door NXP. Sindsdien begint CE meer en 

meer een eigen koers te varen met haar deel van de software stack. De NHSW architectuur ligt vast 

in een “architectural notes” document vol met regels en regeltjes voor ontwerpen, coderen, opslaan, 

structureren, gebruikte tools enzovoort. 

Toen ze gingen samenwerken is afgesproken dat de software voor de MIPS zou worden gebaseerd 

op Koala, en de software voor de TriMedia zou worden gebaseerd op COM, maar met een Koala 

sausje. Verder zou men op weg gaan om de interfaces naar de driver laag te gaan baseren op COM 

(IDL) interfaces. Voor Philips Semiconductors was dit een must, omdat veel van zijn klanten geen 

Koala gebruiken. Dit heeft geresulteerd in de Philips standaard NHAPI die inmiddels is opgevolgd 

door de algemene standaard UHAPI. Omdat de drivers gedeeltelijk op de MIPS zijn 

geïmplementeerd, is de COM methode ook in gebruik genomen tussen software componenten op de 

MIPS. Inmiddels is KOALA uitgebreid zodat met een mix van Koala interfaces en IDL interfaces 

kan worden gewerkt. Van UHAPI is een beschrijving te vinden in Wikipedia (Engels). 

Communicatie tussen TriMedia componenten en MIPS componenten en componenten van de 

standby processor gebeurt altijd op basis van idl interfaces proxy/stub programmatuur, en runtime 

binding. Proxy en stub communiceren met elkaar middels remote procedure call's (RPC). 

Er is afgesproken om Koala integraal te gebruiken, hoewel het gebruik voor TriMedia software 

minimaal is: de h files die door de idl compiler worden gegenereerd worden niet rechtstreeks 

ingelijfd in de betreffende c files, maar vermeld in de cd file van de betreffende Koala component 

zodat Koala deze inlijft in de h file die hoort bij de overeenkomstige c file. Koala is hier vooral 

bedoeld om de de eigen build methode te vervangen door Koala met recht toe recht aan make. Deze 

de overgang is overigens niet van de ene op de andere dag gerealiseerd, en misschien niet eens 

volledig. 

1.4.2 Robuuste overgangen 

Met de keuze voor een component model is er ook gekozen voor struise overgangen. 

Infrastructurele wijzigingen dat zijn ze, de wijzigingen van interfaces. Afgesproken is dat interfaces 

niet wijzigen, als ze eenmaal zijn uitgegeven. Ze kunnen wel worden opgevolgd door een andere 

interface. Een component in zijn rol van server, kan een reeks opeenvolgende interfaces 

implementeren. Een component in de rol van client kan op een geschikt moment gewijzigd worden 

zodat die daarna de meest recente interface gebruikt. Pas als de laatste client over is wordt een oude 

interface beëindigd, en zijn implementatie uit de server verwijderd. Dit is de standaard methode. De 

methode kan ook omgekeerd werken. Als er diverse servers zijn kan een client een server 

ondervragen, en zich bedienen van één van de interfaces die de server aanbied. Pas als de laatste 

server en de laatste client over zijn naar de nieuwere interfaces worden de clients en servers 

vereenvoudigd door oude interfaces te verwijderen. Afhankelijk van de scope van de interface kan 

Pagina: 26 / 230


1 Inleiding 


de methode gebruikt worden om overgangen binnen een subproject, of binnen een master project te 

realiseren. 

Soms, als er sprake is van een interface tussen slechts twee componenten of tussen modules die 

onderhouden worden door één team, worden software en interface wel eens gelijktijdig gewijzigd. 

In een enkel geval waarin de twee componenten beheerd worden door verschillende teams, sturen 

ze elkaar wel eens “baseline supplements” (patches) om de gelijktijdige wijziging te realiseren. Dan 

moeten ze er wel zeker van zijn dat de interface niet elders in gebruik is. Vaak is er enige tolerantie 

voor gemaakte fouten. Maar als er iets mis gaat met de invoering van een interface wijziging dan 

krijg je de wind van voren: “Waarom heb je de standaard niet gevolgd? Je weet toch dat je een 

interface niet mag wijzigen”. 

In een enkel geval wordt gebruik gemaakt van configuratie files, versie-nummers, of creatievere 

methoden (hardware herkenning bijvoorbeeld) om de situaties te herkennen, waarvoor software in 

een overgang bruikbaar moet blijven. Ook is er de mogelijkheid om al dan niet met dezelfde 

interfaces een opvolger van een component te maken, en de oude pas weg te gooien als de nieuwe 

in gebruik genomen is. 

Zonder robuuste overgangen is teamwork en inter teamwork bij het maken van software 

waarschijnlijk zeer veel minder productief, en in ieder geval veel lastiger te organiseren. Van belang 

blijft het opruimen van oude oplossingen, als nieuwe volledig zijn geïmplementeerd. 

Tussen NXP en CE was er een procedure afgesproken. Bij de creatie van een nieuwe interface werd 

afgesproken op welk tijdstip de oude mocht vervallen. De nieuwe interface komt te staan in de 

folder ..\interfaces, de oude komt in ..\interfaces\obsolete, en verdwijnt daar op of na de afgesproken 

datum. Logisch, want het liefst hebben we de software simpel en toegespitst op bestaande situaties. 

Voor de andere oplossingen om overgangen met redundancy op te lossen, zijn geen afspraken 

gemaakt over opruimen en staat er niets in de “architectural notes”. 

Pagina: 27 / 230


1 Inleiding 


1.4.3 Folder structuur en builds 

Vereenvoudigde NHSW structuur 

Toen Philips Semiconductors (nu NXP) en 

Philips CE gingen samenwerken om een 

hybride TV te maken, was er een 

standaard folder-indeling van CE en één 

van SC. Er is toen een nieuwe folderindeling 

afgesproken door de architecten 

van beide industrie groepen. 

Normaal is de path-name van een folder 

de name-pace van zijn inhoud. Voor de 

NHSW tree gold echter dan componenten 

binnen de tree een unieke naam moesten 

hebben. Toen dat niet meer was vol te 

houden is besloten dat componenten een 

unieke naam moeten hebben binnen een 

package, dus in Koala wordt wordt een 

component nu aangeduid met een package 

name en een component name. De 

package naam wordt in de nieuwe pd file 

als name-space gezet. Ieder package heeft 

een pd file in zijn top folder waarin de 

namen worden vermeld van de packages 

waarvan componenten worden gebruikt. 

Als meerdere componenten dezelfde naam 

hebben dan wordt ze in de pd files een 

alias toegewezen. 

Toen ik NXP verliet werd de “builds” 

folder niet gearchiveerd in een revision 

control system, en ik heb niet meegemaakt 

dat de “project” folder enige inhoud had. 

Een folder als “connmgr” heeft typisch 

een package structuur, terwijl de 

subfolders in “private” en “public” typisch 

een opsomming zijn van componenten die 

een component structuur hebben, hoewel 

daarin ook een folder voorkomt met de 

naam “interface”. 

Deze folder-structuur is momenteel één enkele boom, voor alles wat er geproduceerd wordt aan 

program libraries, en executables en dergelijke. In de eerste fase van een build ontleedt Koala alle 

Koala files in de boom, ook als ze niet nodig blijken te zijn voor het target van de build procedure. 

Gezien de omvang inmiddels (tientallen gigabytes) zal in de toekomst waarschijnlijk gezocht 

worden naar een manier om van een boom over te gaan op een bos van kleine bomen, die zoveel 

mogelijk onafhankelijk van elkaar kunnen worden bijgehouden, en ieder een eigen executable 

Pagina: 28 / 230


1 Inleiding 


binary levert, met misschien een dynamische library. Als de TV start moet dus van elke tree uit het 

bos een binary worden geladen, want deze binaries moeten samenwerken. Ontwikkelaars zouden 

dan mogelijk minder tijd kwijt zijn aan het uitvoeren van build procedures. Deze weg is ingeslagen 

door CE die, ik meen in een “SPACE” folder, een aantal van de applicatie, product en tool packages 

heeft geplaatst buiten de NHSW tree (in een super tree), en daarop eigen build procedures gebruikt. 

Binnen de NHSW tree bleven: Tools, Middleware, Operating system, Audio/Video. Ik neem maar 

aan dat dit een trend is die doorzet. 

Iets dergelijks bestond reeds, Er is een MIPS executable, voor iedere TriMedia is er één, voor de 

stand-by processor is er één, (voor de DSP's natuurlijk ook, maar die staan niet in de folder 

structuur). Maar op de dag dat ik gepensioneerd werd was dit niet gerealiseerd in de folder 

structuur. Source code voor de één kan in principe zelfs staan in dezelfde folder als die voor een 

ander. 

De folder structuur herbergt packages (subsystems). Packages bevatten “private” en 

“public”onderdelen. Het is de bedoeling dat software in andere packages slechts refereert aan public 

onderdelen, zodat er voor de beheerders van het package nog enige implementatie vrijheid blijft 

bestaan. Met de nodige mitsen en maren kan gesteld worden dat een wijziging in een package die 

het publieke deel daarvan intact laat, slechts regressie kan veroorzaken in het eigen package. De 

mitsen en maren worden ook wel “semantisch” genoemd: het publieke deel moet ook semantisch 

intact blijven. Tot nu toe is het de gebruikers van een package altijd weer gelukt om aan te tonen dat 

het semantisch inzicht van de beheerders onvolkomen is. Het standpunt van de beheerders is 

evenwel dat gebruikers zich moeten beperken tot gebruik van het package binnen de semantische 

begrenzingen, hoe onvolkomen die ook zijn beschreven: “je kunt het toch wel aanvoelen”. Tot de 

publieke onderdelen behoren de public components, public interfaces, en public data definitions. 

De folder structuur is niet van de éne dag op de andere tot stand gekomen, hij is ontwikkeld, en dat 

heeft geleid tot verhuizingen van de source code. Zelfs de package indeling is aan wijzigingen 

onderhevig. Het systeem dat ik ga beschrijven zou dat moeten faciliteren, maar ik denk momenteel 

dat dat gedeeltelijk lukt voor herstructureren binnen een package, maar dat het me niet lukt voor 

herstructureren over packages. Niet dat het niet kan, maar het revision control system levert geen 

support: er kan geen verwantschap vastgelegd worden tussen twee programma's die in 

verschillende packages voorkomen. 

1.4.4 Afbakening NXP 

De eerste Digitale TV die werd ontwikkeld was voor wat betreft de MIPS software gebaseerd op 

een bestaande software stack van CE. Het MIPS gedeelte dat NXP voor zijn rekening nam bevatte 

nog een ruim aandeel “applicatieachtige” functionaliteit, Bijvoorbeeld het bijhouden van de 

frequenties en eigenschappen van TV stations, of het kiezen van het beeld-formaat. De API 

(verzameling interfaces van de NXP laag) bevatte daarvoor veel functies. Momenteel trekt NXP 

zich terug op een “driver layer” die aangestuurd wordt via een “glue layer”. Dit in de hoop op 

kleinere en snellere “design-in” projects. 

Het package UHAPI bevat de interfaces, die de samenwerking van middleware met de driver laag 

Pagina: 29 / 230


1 Inleiding 


definiëren. Gegevens hierover zijn te vinden in Wikipedia. Ik heb eerst gewerkt met de interfaces 

van Philips CE, en heb daarna voornamelijk gewerkt aan de overgang naar voorganger NHAPI. De 

interfaces van NHAPI werden gebruikt als basis applicatie interface. In design-in en reference 

projects wordt NHAPI vaak uitgebreid met interfaces die de noviteiten in de chip aansturen. 

Ditzelfde gold indertijd voor UHAPI, ook die biedt een basis set. 

Er zijn klanten die bediend worden met een volledige software stack, en zelf bijvoorbeeld een logo 

toevoegen. Dit zijn OEM leveranciers. Voorheen had NXP een eigen software afdeling voor de top 

lagen, maar momenteel wordt deze software bijdrage uitbesteed. 

1.4.5 Diversity 

Sinds jaar en dag prefereren de tv fabrikanten één enkele productlijn in hun fabriek, met één enkel 

software programma voor alle regio's en alle variëteiten. Dit betekent: diversity wordt vastgesteld 

bij het aanzetten van de TV: runtime oplossing. Maar geheugen was duur en dus schaars in 

televisies, en de microprocessoren hadden hun beperkingen, en dus soms moest er toch gewerkt 

worden met meerdere software varianten en werden sommige variabelen in de runtime omgeving 

constanten in de compilatie omgeving. Welke variabelen? Dat varieerde natuurlijk. In de ene serie 

waren het vooral regio gerelateerde codes, in een andere vooral model en functionaliteit 

gerelateerde codes. 

Koala wordt gebruikt om “diversity” efficiënt te verwerken. Soms weet je voor een TV waarvoor je 

software ontwikkeld al van te voren (op compilatie tijd) wat de diversity optie is, Voor een andere 

TV set moet je dit op run tijd detecteren. KOALA zorgt dat je de diversity in beide gevallen met 

dezelfde source code kunt bevragen. De object code die gegenereerd wordt door de compiler is 

compacter, als reeds op compilatie tijd bekend is welke optie geldt. Een van de technieken die de 

compiler gebruikt heet “dead code elimination”: de source code voor condities die niet gelden wordt 

verwijderd. Vaak wordt deze techniek gebruikt samen met een techniek die “constant propagation” 

wordt genoemd. Methoden die code optimaliseren zijn reeds in de jaren zestig en zeventig 

ontwikkeld. De diversity parameters die of op runtime of op compilatie tijd een waarde kunnen 

krijgen waren er in ieder geval al in de jaren tachtig. Toen besloten is om over te gaan op een 

componenten structuur, is er veel aandacht aan besteed om dit te behouden, en zelfs te verbeteren. 

Vandaar dat de componenten van KOALA geen binaries zijn, maar folders met source code. 

Het Koala engine zorgt ervoor dat bij een ”start” module in een component (vergelijk het maar met 

de ”main” procedure in C) de componenten en modules worden gezocht die samen een executable 

vormen. Dit gebeurt via de “interface instances”. Ook dit engine wordt gestuurd door diversity, en 

voert “dead code elimination” uit op het niveau van componenten en modules , die wel of niet 

meegenomen worden. 

Voor de herbruikbare C source code betekent dit ook wel iets. Soms geldt: 

#define a b 

soms 

int a = diversity_a(); 

met alle consequenties van dien voor wat betreft het gebruik van parenthesis (), switch statements 

enzovoort, bij een referentie naar a of b. 

Het streven is ooit geweest om de laatste software versie van NXP te kunnen gebruiken in alle 

vorige projects en dit te realiseren met diversity. Maar zodra gewijzigde software niet meer getest 

Pagina: 30 / 230


1 Inleiding 


wordt op een vorige televisie, dan is ze daar niet meer betrouwbaar. (Het is zelfs zo dat in de 

allerlaatste fase van een project, als tests nog haast uitsluitend plaatsvinden op builds van het 

“product”, dat dan een build voor het testen met een test harness vaak mislukt. Dit is een algemene 

regel: als verificatie ontbreekt, dan is regressie het gevolg. De “standaard” diversity is belangrijk 

voor een snelle aftrap van een project. De diversity tussen de modellen binnen een project moet 

zich vaak ontwikkelen binnen het project. 

Binnen de NXP packages werd diversity als volgt geïmplementeerd. Basis is een aantal parameters 

die de variant van de televisie beschrijven. Iemand gaat werken aan een component (delta 

processing of zo) en komt er achter dat de component varianten en instellingen niet rechtstreeks 

afhankelijk zijn van de basis, maar daar door logica en berekening uit zijn af te leiden. De varianten 

van de component hebben hun eigen parameter set. Er is in het begin is er een diversity component 

gemaakt die middels een diversity interface bevraagd kon worden om de diversity van een 

component te leveren. Nu maken de componenten deel uit van componenten die een platform deel 

representeren, platform delen zijn componenten binnen de platform component en naast de platform 

component staat de diversity component. De diversity interfaces van de kleine componenten werden 

in het platform deel verenigd tot een grotere interface, en in het platform tot één geheel. Nu kwam 

het voor dat sommige componenten om dezelfde diversity parameter vroegen. In de samengestelde 

interface kwamen dus functies in enkelvoud voor die in de platform cd file tot een return waarde in 

meerdere interfaces moest leiden, en zo ook in de deel platform cd file. Toen dit systeem bedacht en 

geïmplementeerd werd door mensen voor wie Koala nieuw was, (en misschien kon Koala toen nog 

niet wat nu mogelijk is) is dit zo gebeurt dat in de diversity module van een (deel) platform 

component ieder functie call vanuit een component afzonderlijk opgeloste met een functie call via 

de samengestelde interface. Dit bleek zeer onderhoudsgevoelig. Voor diversity interfaces maakten 

we trouwens een uitzondering, geen enkele wijziging leidde tot een nieuwe interface, deze interface 

mocht gewoon wijzigen. Ondanks de onhandigheid, is er in geen van de projects erna besloten tot 

herontwikkeling. 

Als er in product family een tv voorkomt waarvan een eigenschap op compile time bekend is dan is 

die eigenschap een diversity parameter. Voor diversity geldt als ze in één van de andere televisies 

geen compile time diversity is dat ze moet zijn te determineren door automatische detectie van 

hardware karakteristieken, of dat ze moet worden opgegeven door een fabrieksmedewerker, of door 

een dealer, of door een eindgebruiker. Normaal worden de run time diversity parameters 

vastgesteld tijdens initialisatie van het systeem. Als de diversity wordt ingesteld door dealer of 

fabricage medewerker, dan moet opnieuw worden gestart om de wijziging te activeren. Maar van 

een eindgebruiker wordt dit doorgaans niet verwacht. Wat tussen sommige televisies diversity is, 

kan in een andere een gebruikers optie zijn. Ik heb nog niet gezien dat dit met diversity is geregeld. 

Het binden van parameters aan waarden mag dan gebeuren tijdens initialisatie, maar dat betekent 

niet dat de diversity alleen dan geraadpleegd wordt. Raadplegen gebeurt voortdurend. 

Tuner karakteristieken maken deel uit van de diversity. Proactief worden van tuners de 

eigenschappen vastgelegd. Iets soortgelijks geldt voor onderdelen als beeldschermen. Tuners en 

beeldschermen zijn in ieder geval voor een deel op compile time bekend. Soms wordt in de fabriek 

gekozen uit enkele typen, dan is op compile time de selectie bekend. 

Andere zaken die mogelijk proactief bijgehouden worden, maar vaak ook het gevolg zijn van field 

calls, of field tests. Soms wordt van een bepaald invoer apparaat geconstateerd dat zijn signalen 

beter afwijkend kunnen worden behandeld. Soms geldt dit voor de signalen van kabel exploitanten, 

Pagina: 31 / 230


1 Inleiding 


en tv stations. De dealer kan soms informatie geven over de signaal leveranciers ter plekke. Maar 

toch, de eigenschappen van invoer-apparaten en kabel exploitanten en dergelijke kunnen momenteel 

beter uit een database van het internet opgehaald worden. Die van kabel exploitanten veranderen, tv 

stations komen en gaan en apparaten komen er steeds meer. Er wordt steeds meer 

gestandaardiseerd, en certificering kan groeien in kwaliteit. Soms kan iets dat eerst mogelijk met 

diversity geregeld was, eruit verdwijnen. 

1.4.6 Koala / Horcom 

Koala is gemaakt voor resource restricted systems. Dit zijn kleine micro computers met weinig 

geheugen en processing power. Ook is Koala gemaakt voor product families, en implementeert ze 

efficiënt diversity. De bijdrage aan de diversiteitsafhandeling wordt nog steeds gewaardeerd. De 

processoren in de TV chip kun je niet meer zo heel erg resource restricted noemen, maar daarvoor 

geldt baat het niet het schaadt ook niet, en uiteindelijk is Koala enigszins uitgebouwd voor COM. 

Diversiteit wordt gebruikt om bij elk source programma een toegespitste h file te maken, nou ja niet 

bij allemaal, alleen degenen die van belang zijn voor een bepaalde televisie. De compile time 

oplossingen van Koala profiteren van het feit dat er in een televisie veel singleton componenten 

voorkomen, of enkele met name te noemen instances. Zo is er slecht één tuner, en slechts enkele 

decoders (een decoder kan slechts enkele signaal-soorten decoderen), enzovoort. In veel televisies 

kan men werken met een “Dual Window” of met “Picture in Picture” Dan moeten er voldoende 

component instances zijn voor de verschillende video-stromen. Bij deze componenten hoort ook 

slechts één driver. De component instances hoeven meestal niet dynamisch gecreëerd te worden en 

de interfaces behoeven meestal niet dynamisch te worden gelegd. Koala is in deze situatie goed op 

zijn plaats. De componenten staan in een statische structuur, en de interfaces zijn vaste 

verbindingen tussen de componenten, die tijdens compilatie gedeeltelijk met behulp van “inline” 

code worden gerealiseerd. Een component die 2 instances realiseert implementeert soms twee sets 

“instances” van dezelfde interfaces. De ene set kan verbonden zijn met client component A, en de 

andere met B. De compile time binding van Koala werkt samen met een optimizing c compiler en 

zo wordt door Koala en compiler geoptimaliseerde code geproduceerd. 

Een verstoring van dit beeld treedt op omdat er in tv's gezapt en geschakeld wordt. Als je zapt van 

een analoge tuner naar een digitale dan moet het signaal een andere route gaan volgen; als je naar 

een dvd speler kijkt moet het signaal een andere route volgen dan wanneer je kijkt naar een 

uitzending: de componenten moeten zich steeds anders aaneenrijgen om een route te maken. Voor 

hardware componenten wordt dit geregeld met hardware switches en blijft het statische beeld 

feitelijk intact, maar voor TriMedia (software) componenten wordt het signaal pad geformeerd, 

door de betreffende component instances dynamisch te creëren en dynamisch te linken aan 

voorganger en opvolger. Ook dan blijft het vaak singleton werk, want er kunnen slechts enkele 

signaal-stromen tegelijk door een televisie lopen. Een en ander heeft ertoe geleid dat de hardware 

routes worden geregeld met “Horcom”, terwijl TriMedia routes worden geregeld door een 

“Connection Manager”. Een ontwikkeling die nog altijd door mij wordt betreurd, het had met één 

methode gekund: “Horcom vernieuwd”. 

“Horizontal communication: a style to compose control software”, Rob van Ommering Software 

Practice & Experience Volume 33 , Issue 12 (October 2003) . 

Pagina: 32 / 230


1 Inleiding 


Horcom discussies, gesprekken bij de koffie automaat 

Sommigen binnen NXP wil eigenlijk af van Koala, omdat Philips CE de enige klant is die ermee 

werkt. Voor NXP zelfstandig werd nam PS het onderhoud over van CE als ik mij goed herinner, 

maar ik geloof niet dan het beheer meegenomen is toen PS NXP werd. Binnen PS was het 

misschien wel stiekem de bedoeling om het te killen. Maar tot nu toe is de berg eigen NXP software 

waarin het gebruikt wordt te groot om het weg te gooien, bovendien heeft men met Koala ook 

beheerders en gebruikers overgenomen, en die willen van geen wijken weten. Koala is typisch zo'n 

methode waarvan je denkt dat je hem beheerst, terwijl je er eigenlijk gewoon aan verslaafd bent. 

Wat voor Koala geldt geldt ook voor Horcom: CE is de enige klant die ermee werkt, en eigenlijk 

willen sommigen er daarom van af in de hoop beter aan te sluiten bij de rest van de markt. Veel 

klanten gebruiken geen NXP tuner, en geen NXP channel decoder, of vullen de chip aan met eigen 

chips of bolt-on boards, en komen daarvoor dan met eigen software: de platform software werkt 

dan slechts ten dele met Horcom, of via omwegen of gedeeltelijk imiteren worden de componenten 

van de klant opgenomen in Horcom. Daar staat tegenover dat NXP zeer veel heeft geïnvesteerd in 

de platform besturingssoftware die er nu is, met een project van tussen de veertig en zestig mensen 

gedurende meer dan een jaar. In feite was het project de allerlaatste poging om een digitale tv op 

de markt te zetten. Koala en Horcom maken deel uit van, of misschien wel “zijn”, de infrastructuur 

van de platform besturingssoftware. Als je ze vervangt moet je feitelijk overnieuw beginnen. 

Vandaar misschien de methode: reuse en langzaam terugdringen. 

Horcom als architectuur principe. Het idee is duidelijk. De componenten structuur van de hardware 

wordt nagevolgd door de software. In principe is dit een anti reuse bepaling: je volgt niet de 

structuur van de vorige software generatie, maar de structuur van de huidige hardware (en 

TriMedia) componenten, dus reuse is komt hoogstens voort uit reuse van onderliggende 

componenten. Dit volgen van de structuur betreft overigens niet de hiërarchische structuur maar 

uitsluitend de netwerk structuur: het transformatie model zeg maar. Ondanks dat dit eigenlijk heel 

duidelijk is, is er toch altijd wel tegen gezondigd. Het is gewoon te verleidelijk om software 

opnieuw te gebruiken, en wat te knutselen om het werkend te maken. 

Het capability model van Horcom is te simpel. Oorspronkelijk zou een Horcom node de volledige 

verzameling capabilities van de onderliggende transformatie component vermelden, maar 

uiteindelijk werden slechts de signaaleigenschappen geregistreerd die de component kon 

vaststellen. Voor deze data is een simpele methode gekozen, zonder zaken als information hiding. 

Dit alles was gerechtvaardigd op de vroegere kleine micro computers met weinig geheugen, maar 

nu is er behoefte aan betere methoden, zoals uit de twee volgende paragrafen blijkt. 

De taken van Horcom: connection management en het verzorgen van de (bidirectionele: upstream 

en downstream) communicatie tussen de componenten in de transformatie laag. Connection 

management is op te delen in verschillende taken, zoals het bepalen van de blanking en muting 

periode tijdens een zap, het afbreken van de oude routes en het instellen van de nieuwe, Het 

beëindigen en opnieuw bemiddelen tussen de transformatie componenten die gegevens produceren 

en degenen die informatie behoeven. Met de introductie van de “com” component methode zou 

daar een deeltaak bij moeten komen: het dynamisch koppelen en ontkoppelen van de bestuurlijke 

interfaces (van UHAPI) aan de componenten in de transformatie laag. Het bedienen van zo'n 

interface is natuurlijk ook een “capability” van de component. 

Ook het binden van interfaces tussen de laagste besturings-componenten ontbreekt. Veel van deze 

componenten zijn één op één vast gerelateerd met drivers, en daarmee vast gerelateerd aan een 

Pagina: 33 / 230


1 Inleiding 


Horcom node. Met name de engineers van het audio gedeelte implementeerden een Horcom node 

met besturingsinterfaces zonder onderliggende transformatie component, en vandaar uit een 

complex geheel aan route begeleidende (KOALA) interfaces naar nodes die wel een onderliggende 

transformatie component bedienen, zo omslachtig zelfs dat het plug en play karakter verloren is 

gegaan. Het stromen model van de eerste chip die we programmeerden kon daardoor nog steeds 

herkend worden in de software voor de laatste chip die ik heb meegemaakt. Via deze interfaces 

vindt zowel gegevens uitwisseling plaats als ook besturing. Die route begeleidende interfaces 

hebben duidelijk een work-around karakter. Ze zijn er omdat Horcom ze niet biedt. 

Toen MG-R en DVP geïntegreerd werden ontdekte men van elkaar aan de ene kant Horcom, en aan 

de andere kant TSSA (TriMedia Streaming Software Architecture) Men startte de discussie met ze 

als alternatieven te zien. De volgende twee paragrafen zijn het resultaat van de discussies toen. 

Een deel van de Horcom discussies zijn analoog aan de delegeren of besturen discussies in 

verticale organisaties. Er is de vaststelling dat veel van de horizontale communicatie “met de 

stroom” meegaat, en dus als metadata met de stroom meegestuurd kan worden, zoals je in een 

fabriek halffabricaten kunt transporteren in een bak met een kaart met streepjescodes. De 

informatie-stroom in tegengestelde richting zou te gering zijn voor een algemene oplossing, en zou 

dus maar met incidentele oplossingen moeten worden bewerkstelligd. Dus waarom dan nog 

Horcom? Eigenlijk was dit een opvatting gebaseerd op het gegroeide idee dat er slechts data 

uitgewisseld wordt tussen transformatie componenten. In de praktijk wordt er ook data van of voor 

het management horizontaal uitgewisseld, en worden opdrachten in stukjes geknipt en doorgegeven 

aan de transformatie-laag. Dit komt omdat Horcom het enige horizontale management platform is 

in de TV. Zo zijn er zelfs enige Horcom nodes zonder een bijbehorende transformatie component. 

Zonder deze nodes zou mogelijk een “verzuilde” besturingslaag zijn ontstaan, terwijl nu de 

verzuiling alleen bestaat voor de Horcom nodes, de drivers en hun onderliggende transformatie 

componenten (in het audio gedeelte is het wel wat complexer geworden, dan kleine zuiltjes). 

Zuivere verzuiling zou de toenemende rol van applicaties hinderen. Het verdelen van applicatie 

informatie naar transformatie componenten, het verzamelen van informatie t.b.v. applicatie 

componenten en het verdelen of herindelen van opdrachten komt deels omdat er op transformatie 

niveau creativiteit toegestaan wordt met de component indeling. Daardoor past een UHAPI 

interface niet altijd precies op één hardware component, of één TriMedia component. Voor een 

ander deel omdat er altijd wel enige redundancy bestaat in de transformatie laag waardoor er keus 

is waar een bewerking of een waarneming moet plaatsvinden. Die keus wordt doorgaans 

gerealiseerd in de management laag, dus in het horcom netwerk. Die redundantie is er bijna zeker, 

als de NXP chip wordt begeleid door elektronica die niet van NXP afkomstig is, en soms ook als 

additionele elektronica wel is geleverd door NXP, en af en toe is ze er zelfs binnen de one-chip 

televisie. 

Het andere deel van de discussies is een plug en play discussie. Horcom heeft een typisch plug en 

play aspect: plaats een Horcom node in het model en de onderliggende transformatie component 

kan worden bestuurd en doet mee met connection management. Al moet je naar de hardware nog 

wel een driver maken, en vaak de driver aansturen vanuit een functionele module. Dit heeft 

natuurlijk een prijs: 

bij elke zap, en bij sommige signaal veranderingen, wordt voor elke output (speakers, window, 

connectoren) een route gezocht naar de gewenste input. Iets zoeken is natuurlijk minder snel dan 

iets pakken. 

Het vaststellen van de blanking periode (drop/restore logica) gebeurt door meerdere malen 

Pagina: 34 / 230


1 Inleiding 


sequentieel routes in het netwerk te doorlopen. 

De daadwerkelijke gegevens uitwisseling werkt eveneens, door sequentieel routes langs te gaan om 

componenten te notificeren. 

De routes worden doorlopen doordat iedere node op zijn beurt de betreffende functie aanroept in 

een naastgelegen node. Dit betekent dat een zeer grote call-stack moet worden bijgehouden. 

De tegenstanders van Horcom bepleiten als oplossing: houdt het model buiten de TV software 

(desnoods op een schoolbord), doe daar een model zap, registreer wat er dan gebeurt, en breng het 

geregistreerde aan in de TV software. Daartoe gebruiken ze dan in de TV de “connection manager” 

voor het koppelen van interfaces aan platform componenten, en het kennis systeem voor de register 

waarden (inclusief switches). 

In wezen betreft deze discussie dus het wel of niet verplaatsen van acties in de runtime omgeving 

naar het ontwerp stadium. 

Om reeds in de design fase (van de chip of de set) een Horcom model te maken is natuurlijk een 

goed idee. Je kunt ermee testen of alle signaal paden altijd over voldoende resources kunnen 

beschikken, en misschien ook of elkaar storende onderdelen tegelijk actief kunnen zijn. 

De keuze om het audio / video netwerk te modelleren met KOALA interfaces tussen Horcom nodes 

is niet helemaal gelukkig. Er zijn inmiddels veel nodes in dit netwerk, dus Horcom nodes zijn geen 

singletons (er zijn er aanzienlijk veel meer dan één of twee). Met KOALA interfaces is er is een 

aanzienlijke hoeveelheid node specifieke code. Dank zij uitgekiende Horcom macro's is de 

hoeveelheid primaire source code beperkt, maar na macro expansie is er relatief veel c code: 

Horcom is een geheugen vretertje. We zouden misschien beter over kunnen gaan op een netwerk 

structuur opgebouwd uit objecten met vtables, die met elkaar verbonden zijn middels pointers. 

De meeste horcom nodes hebben meer dan één ingang en meer dan één uitgang. Nodes tot nu toe 

zijn: source, destination, one-to-one, fork (die zorgt voor een vertakking van een input signaal in 

meerdere output signalen), switch (dit is altijd een source selectie switch: de output pinnen worden 

erdoor gegroepeerd in clubs die naar dezelfde input pin kijken of luisteren, of mogelijk één output 

pin die afwisselend kan kijken naar steeds één input pin tegelijk). 

Als je twee forks bekijkt dan kan de éne het volledige signaal splitsen in 2 volledige signalen, 

terwijl de ander het signaal ontleedt in onderdelen die ieder een eigen route volgen. Bijvoorbeeld 

audio/video wordt gescheiden, of een video signaal splitst in een Y route en een BlueRed route. Er 

zijn ook hybride forks waarin een gedeelte van het signaal voorkomt in meerdere teeth. 

Forks in het Horcom model hoeven niet altijd te bestaan in de hardware: in een scart plug 

bijvoorbeeld heeft ieder signaal zijn eigen poort, maar in het horcom model zijn die gebundeld in 

één route bij de source node, en wordt de route met een fork gesplitst in een audiogroep, een 

CVBS/YC groep en een RGB groep. 

We missen nog één type, een tegenhanger van de fork, waar signalen bijeen komen, zoals in de 

video mixer, waar dual windows en menu's kunnen samenkomen in het screen, en de video decoder 

van de oorspronkelijk analoge signalen, waar sync signalen binnenkomen die een andere route 

hebben afgelegd dan de RGB signalen, en waar het luminance signaal via een andere route 

binnenkomt dan de chrominance signalen. De trajecten achter de mixer en vóór de decoder zijn 

inmiddels significant. 

De tegenhanger van de signaal ontledende fork, bijvoorbeeld de analoge video decoder zou 

composer genoemd kunnen worden of counter-fork. 

Mogelijk wordt de mixer geïmplementeerd met twee half autonome horcom netten, immers zijn 

Pagina: 35 / 230


1 Inleiding 


output is een source voor het net dat er op volgt, terwijl zijn inputs een destination zijn van het net 

dat eraan voorafgaat. Achter de mixer is er bijvoorbeeld een netwerkje met een route voor de 

onmiddellijke ongebufferde presentatie van de video van spelcomputers en de route met frame 

buffers die dienen voor het plausibel presenteren in de beeld frequentie en resolutie van het scherm. 

(Tijdens de nationale voetbal gekte hebben de huizen in de straat waaruit het eerst een gejuich 

opstijgt nog een ouderwetse analoge tv, met een analoge provider en de huizen waaruit het gejuich 

een aantal seconden later komt een digitale met veel (frame) buffers tussen camera en scherm). 

Er is een idee om switch en fork te combineren zodat in de ene tv een input en een output pad “hard 

coded” of middels diversity gekoppeld kunnen zijn, terwijl in een andere dynamisch middels 

switchen gekoppeld wordt. Die diversity bijvoorbeeld geeft hardware ontwerpers de mogelijkheid 

om een plug de ene keer aan te sluiten op poort A van de chip, en de volgende keer op poort B. De 

huidige implementatie met macro's mist die mogelijkheid, waardoor de diversity methode die nu in 

gebruik is erg omslachtig is. Het is typisch een work-around oplossing. 

Er lijkt soms een tegenstrijdigheid te bestaan: om switches consequent met Horcom te regelen is er 

een verfijnd netwerk nodig, waarin ieder subsignal zijn eigen route krijgt. Voor het communiceren 

met drivers is er een minder verfijnde structuur nodig waarbij één enkele horcom signaal route een 

driver aandoet. (Mogelijk zal er wel altijd een grijs gebied zijn waarin een setting kan worden 

beschouwd als een switch, of als een gewone setting.) 

Er is ook een idee om input selectie switches te implementeren in de software als “open/close 

switches” aan de input zijde, waarvan er tegelijkertijd slechts één open mag staan. Zo'n switch kan 

dan soms reduceren tot een output die slechts verbonden is met één switch. 

De combinatie connection manager / horcom is niet bepaald gelukkig. De huidige connection 

management component ziet eruit als een kind met een waterhoofd. Ook dat is een reden om het 

hele concept te herzien. 

Inmiddels is de connection-search-method behoorlijk geoptimaliseerd, zijn computers snel, en zijn 

er design patterns beschikbaar voor gegevens uitwisseling (bijvoorbeeld observer en callback). 

Ook zouden iteratieve methoden kunnen worden gebruikt, in plaats van call stacks. dus ik zou 

zeggen gebruik het Horcom model in de TV voor connection management, het opzetten van 

upstream directed communication die afkomstig is van transformatie componenten, en upstream en 

downstream directed information die afkomstig is van management componenten, of die ervoor 

bestemd is. Ook, als je data meestuurt met het signaal naar de volgende component, zou je een 

oplossing kunnen kiezen die verbergt of er horizontaal of verticaal, stroom opwaarts, of met de 

stroom mee gecommuniceerd wordt. 

“Design Patterns, Elements of Reusable Object-Oriented Software” by Erich Gamma, Richard 

Helm, Ralph Johnson, John Vlissides. Addison-Wesly, ISBN 0-201-63361-2 

Voordat de Horcom macro's gemaakt waren, programmeerde ieder zijn eigen horcom nodes, daarna 

was het een kwestie van een paar regels macro's. Dit had een eigenaardig effect. Voor veel 

programmeurs werd het horcom netwerk een geheimzinnige black-box die op magische wijze zijn 

nuttige werk deed. Het was niet langer een gemeenschappelijk concept. Dank zij de macro's was 

ook nog eens knap lastig geworden om bijvoorbeeld breakpoints te zetten, en ook adequaat loggen 

om een fout te ontdekken was een kunst geworden. Toch was horcom vaak belangrijk bij het 

Pagina: 36 / 230


1 Inleiding 


analyseren van fouten. Bij voorkeur werd daarvoor een deskundige ingeschakeld. Ook werden vaak 

toch maar alternatieve foutanalyse methoden gebruikt. Mocht het ooit komen tot een redesign van 

horcom dat zouden debug en logging faciliteiten op toegankelijke wijze geïmplementeerd moeten 

worden. 

Bij Philips-CE in Brugge was horcom een gedeeld concept. In het gezamenlijke CE/SC project 

TvDoc, werden de horcom macro's ontwikkeld, die daarna in het gezamenlijke Jaguar project 

gebruikt werden in de eerste volledig digitale TV (op de meeste inputs en outputs na). In het Jaguar 

project werd horcom een black-box voor het SC team, maar was het nog steeds een transparant 

concept voor het CE team, ondanks de macro's. 

Momenteel is NXP verantwoordelijk voor deze connection management onderdelen. Mogelijk in de 

toekomst laat hij dit over aan zijn klanten. Maar zoals het er bijstaat (anno 2008) draagt NXP niet 

bepaald een gespreid bed over aan die klanten. 

1.4.7 Power modes en hardware die geen deel uitmaakt van het 

audio/video platform 

Als je erover nadenkt besef je dat het netwerk model van Horcom onvoldoende is om alle hardware 

te besturen. Een analogie: het licht knopje van de fabriekshal is niet te vinden in een productielijn. 

Het blijkt dat hardware vaak hiërarchisch is opgebouwd, en niet alleen maar een netwerk structuur 

heeft. Een component die zowel de DAC's (digital to analog converter) als de ADC's bevat bevindt 

zich zowel aan de voorzijde als aan de achterzijde van het transformatie netwerk, en heeft een eigen 

power management, waaraan mogelijk geen recht wordt gedaan als uitsluitend actie wordt genomen 

als een ADC of DAC benaderd wordt in het netwerk. 

Er is software die bestaat uit meerdere componenten: de Power componenten, die ervoor zorgen dat 

precies die hardware en software opgestart is als nodig is voor de onderhanden taken. Hierbij 

kunnen typische Horcom drivers en hardware aangestuurd worden, maar ook kunnen hardware en 

drivers worden aangestuurd die niet met Horcom bediend worden. 

Er zijn diverse power modes, waarbij hardware wel of niet is opgestart. Als 's nachts het 

elektronisch programmablad wordt opgehaald, hoeft het scherm niet aan te staan. In standby mode 

is bijvoorbeeld de stroom afgehaald van MIPS en TriMedia. Je kunt de TV gebruiken als radio, 

zonder video. 

Als je een TV uit standby mode haalt wordt de audio/video mode bereikt via een serie fasen om te 

zorgen dat niet in één klap alles aanstaat, want dat geeft werkelijk een klap, waarbij elektronica kan 

beschadigen. Ook uitzetten loopt om dezelfde reden bij voorkeur via fasen. Ook deze fasen worden 

power modes genoemd. Goed planmatig opstarten is waarschijnlijk ook nuttig om te garanderen 

dat de elk elektronisch onderdeel na het opstarten in de gewenste start toestand staat. 

Enige voorbeelden van hardware buiten het A/V platform: afstandbediening lezen, de wekker, de 

stroom voorziening, het file system, alle communicatie met internet, USB, harde schijven zonder 

dat daar streaming bij betrokken is. Ook deze hardware wordt bedient met drivers, en valt buiten het 

competentie gebied van Horcom. 

Pagina: 37 / 230


1 Inleiding 


1.4.8 Pumps en pump engines 

Van ouds her werkt embedded software met een "main loop" waarin events (messages) worden 

gelezen en afgehandeld. State variables en message types worden gebruikt om de procedure te 

determineren die de message verwerkt. Messages ontstaan door interrupts, en door het gebruik van 

de remote control, en ze worden gegenereerd door procedures in de main-loop. De messages komen 

meestal in een first-in first-out lijst. Soms is er geen lijst, dan mag in een doorgang van de mainloop 

hoogstens één message gegenereerd worden, en wel als laatste actie. 

Momenteel, nu de processors krachtig zijn en geheugen geen probleem, is één van de belangrijkste 

onderdelen van de ondersteunende component “os” het message systeem. In de message queues van 

de televisie kun je messages sturen die naast enige data het adres bevatten van de procedure 

waaraan de message is gericht. Per thread is er een main loop die de messages uit één queue 

afhandelt. Als zo'n message aan de beurt is dan wordt de betreffende procedure aangeroepen, met de 

parameters die in de message staan. Dit is meen ik afgekeken van MS Windows 3.1. Een message 

van een bepaald type wordt een pump genoemd. De message queue en de thread die de message 

afhandelt wordt pump-engine genoemd. De pump en pump-engine definitie stamt uit de MG-R 

poot. 

De software componenten communiceren met elkaar door procedure calls via hun interfaces. 

Methods in de koala interface worden rechtstreeks aangeroepen en niet via dit message 

mechanisme. Calls naar COM componenten, bijvoorbeeld remote procedure calls (RPC), worden in 

proxy/stub modules opgelost met behulp van synchronisatie middelen. Ik weet niet of dit is opgelost 

met de pump implementatie van de component “os”, maar ik vermoed van niet. 

Messages worden meestal gestuurd en ontvangen door procedures die tot dezelfde component, en 

liefst dezelfde source module, behoren. Zo wordt de uitvoering van een langdurig karwei 

opgesplitst in een serie kortstondige brokken, die door dezelfde pump-engine worden uitgevoerd. 

De afhandeling van een functie uit een koala of com interface wordt op deze manier in stukjes 

geknipt. Meestal worden meerdere karweien tegelijkertijd door dezelfde pump-engine afgehandeld: 

meerdere interface functies, van meerdere interfaces worden in stukjes geknipt. Het effect van een 

pump-engine is daarom voor een groot deel: non pre-emptive multitasking. 

Non pre-emptive multitasking met messages doet denken aan non-determinisme. Dat zou in 

overeenstemming zijn met de ontwikkelmethoden voor embedded software: met de DFD's (data 

flow diagrams) die sommige methoden gebruiken die het non-determinisme min of meer 

maximaliseren en het in ieder geval in kaart brengen. Embedded software engineers houden vooral 

daarom van non-determinisme omdat ze het om zeep kunnen brengen: het geeft je keuze 

mogelijkheden voor prioriteiten en daarmee voor volgorden, zodat real time doelen kunnen worden 

gehaald. Prioriteiten worden gerealiseerd door pump-engines te koppelen aan componenten, en 

prioriteiten aan pump-engines. Maar door de enorme hoeveelheid componentjes en message types 

in Tv's blijft er nog zeer veel volgorde ongedetermineerd. 

"Structured Development for Real-Time Systems Volume 1" van Paul T. Ward & Stephen J. Mellor. 

(1985 Prentice Hall ISBN 0-13-854787-4 025) (volume 2 en 3 zijn er ook). 

"Strategies for Real-Time System Specification" van D.J. Hatley & I.A. Pirbhai (Dorset House 

Publishing; New Ed edition (1 Jan 1988) ISBN: 978-0932633118 ) 

Naast non determinisme zijn er in embedded software ook constructies waarbij de prioriteiten 

bijdragen aan de logica, in het ene geval werkt het programma logisch correct, in het andere geval 

Pagina: 38 / 230


1 Inleiding 


fout. Het is de kunst om in de mix van keuzevrijheid en volgorde voorschrift, de brokjes 

programma-doorloop te voorzien van optimaal werkende prioriteiten: als de afhandeling van een 

message logisch moet vooraf gaan aan die van een andere, dan mag zijn prioriteit zeker niet lager of 

gelijk zijn. Een elementair voorbeeld: een implementatie van a=2*(b+1) 

a = b; (1) 

... 

a = a + 1; (2) 

... 

a = a * 2; (3) 

Na uitvoering van statement (1) wordt statement (2) uitgevoerd door afhandeling van message (m1) 

en statement (3) door afhandeling van message (m2). Als iedere message afgehandeld wordt in zijn 

eigen message queue, dan moet message (m1) afgehandeld worden met een grotere prioriteit dan 

message (m2), en message (m2) liefst met een lagere (of gelijke) prioriteit, dan de procedure die de 

messages verstuurde. 

Er zijn twee soorten messages: 

de timed message: de afhandelende procedure moet worden aangeroepen zodra de tijd 

verstreken is. 

De untimed message: de afhandelende procedure moet aangeroepen worden zodra de 

gelegenheid zich voordoet. 

Timed messages gaan vóór untimed messages. Overige prioriteiten worden geregeld met thread 

priorities. Een belangrijke toepassing van timed messages is het “polsen” waarmee hardware 

registers in de gaten worden gehouden. Er lijkt momenteel een tendens te zijn om dit te regelen met 

interrupts, maar de embedded software engineers staan enigszins wantrouwend tegenover 

interrupts: “we houden meer registers in de gaten dan waarvoor interrupts bestaan, en bovendien, in 

elke chipset zijn er weer andere”. 

Polsen: Eigenlijk gebruikten we de term “pollen”. Het Engelse “to poll” is in feite, althans volgens 

mijn woordenboek, periodiek een steekproef nemen (periodiek een deelverzameling doormeten). 

Wij gebruikten het dus om periodiek een register te testen op verandering, dus zonder een 

deelverzameling te trekken. 

Daarnaast zijn er twee opties voor een message type 

● Het meest gebruikt is de optie dat een message van een bepaald type een eventuele 

voorgaande message van hetzelfde type overschrijft. 

● En er is de andere optie: alle messages van een bepaald type moeten worden afgehandeld. 

Er worden zeer veel replacing message types gedefinieerd, in plaats van weinig queuing message 

types, om de inschatting van de grootte van de message queue zo nauwkeurig mogelijk te kunnen 

doen. 

Een message kan door de procedure die de message verstuurd, worden geplaatst in de message 

queue van een bepaalde thread. In het jargon wordt de message queue van een thread een pump 

engine genoemd. Met een dergelijke resource begint de thread nog niet op een task te lijken. De 

component “os” spreekt echter over tasks, en niet over threads. 

Meestal gebruikt een component één (hoofd) task met message queue, zodat andere synchronisatie 

mechanismen, zoals semaphores, critical regions en dergelijke zoveel mogelijk vermeden worden. 

Pagina: 39 / 230


1 Inleiding 


Als een (koala) component een procedure aanroept in een component die een andere task gebruikt, 

dan maakt de caller gebruik van een synchronisatie waarbij de task van de called component wordt 

stilgelegd nadat de lopende message is afgehandeld, de task van de caller wacht hierop. Dan wordt 

de call gepleegd, en daarna wordt de task van de called component weer geactiveerd. 

Remote Control signalen, signalen van knoppen die op de TV ingedrukt worden, audio en video 

veranderingen, enzovoort. Al deze signalen veroorzaken een message op een pump engine. Al het 

pollen (periodiek controleren van een register) wordt geregeld met timed messages. Komt uit dat 

pollen een signalering voort, dan is ook dat ook weer een message. Je hoeft niet altijd te pollen, 

vaak kun je of soms moet je gebruik maken van hardware interrupts. Dan stuurt de interrupt routine 

een message. 

De invloed op de interfaces van de componenten: Bij de meeste requests van een client component 

aan een server component wordt er geen waarde als antwoord geretourneerd, maar wordt later een 

callback procedure in de client aangeroepen door de server, met de afloop van het request. Soms 

biedt een interface een hybride oplossing. Dan wordt er een direct een antwoord geretourneerd als 

dat mogelijk is, maar anders wordt er een callback procedure aangeroepen. Dit is vaak nodig omdat 

de afhandeling van een request vaak in stukjes wordt geknipt met behulp van messsages. Soms is 

dat nodig omdat het tijd kost om iets te meten, soms is het wenselijk omdat gecommuniceerd wordt 

met een functie in een andere thread. 

Koala interfaces bieden geen rechtstreekse faciliteiten voor callback. Er is de mogelijkheid om naast 

een interface die nodig is voor de client en waarin de functie aanroepen staan naar de server, een 

“notify” interface te gebruiken die nodig is voor de server, waarin de functie aanroepen staan naar 

de client. In Koala is dit volkomen symmetrisch opgelost. Callback is een functie aanroep via de 

notify interface. Merk op dat callback iets anders is dan een notificatie, want het initiatief van de 

notificatie ligt bij de server, de server notificeert spontaan, en niet als uitgesteld antwoord op een 

request. 

1.4.9 MIPS recovery 

Als de MIPS crasht blijkt dat de transformatie laag gewoon autonoom doorwerkt, onder het motto 

“managers, waarvoor heb je ze nodig”. Er is een reboot methode bedacht om de MIPS weer op te 

starten, zonder onderbreking van de transformatie laag. Daartoe wordt regelmatig de status 

weggeschreven naar NVM (Non Volatile Memory). Bij het opstarten voor recovery wordt het 

schrijven naar hardware registers of het commanderen van de TriMedia componenten 

tegengehouden, zodat de transformatie laag blijft werken. De status opvragen van de transformatie 

laag blijft wel mogelijk, dat moet zelfs. Deze modus wordt aangehouden totdat de MIPS weer bij de 

tijd is. Zo'n situatie zou zich niet voor moeten doen, maar helaas is er een een TV in de markt 

geweest die dit in het begin regelmatig deed. Tijdens de crash reageerde de TV niet op opdrachten 

met de afstandsbediening, of op de toetsen op televisie. Dit werd doorgaans gemerkt door de 

gebruiker, want de crash was meestal een – verkeerde – reactie op een signaal van de 

afstandsbediening, waarna de gebruiker extra hard en vaak, maar wel te vergeefs, op knoppen 

drukte om te TV te laten doen wat hij wou. Tegen de tijd dat de TV weer reageerde drukte de 

gebruiker vaak op willekeurige toetsen, waarna de TV ook niet deed wat hij wilde. 

Pagina: 40 / 230


1 Inleiding 


1.4.10 Test binaries 

Tijdens ontwikkeling worden niet alleen binaries gemaakt voor het product zoals dat uiteindelijk in 

de tv komt, er is een binary voor het audio/video platform, veel componenten in het platform 

worden getest met het platform harness, omdat hiermee de interfaces naar en van het platform 

kunnen worden gekoppeld aan een script, of kunnen worden gebruikt via een menu op de tv. Veel 

interfaces zijn vast verbonden met een component, daarom kun je er vrij eenvoudig een component 

mee testen. Dan zijn er nog binaries die een test-harnas zijn van een enkele component of een 

enkele source module, en die mogelijk op een desktop of laptop getest kunnen worden: de unit tests. 

Er zijn in principe twee methoden om software te laden en op te starten in een TV. Je kunt software 

uploaden naar het flash geheugen van de TV en dan voortaan van daaruit starten. Upload gebeurt 

met met het installatie tool. Er is ook een methode om software van een externe source rechtstreeks 

te laden in het main memory van de TV. Beide methoden worden gebruikt. De laatste methode 

wordt bijvoorbeeld gebruikt door remote debuggers. Zolang software getest wordt zijn er dus twee 

methoden om de TV te starten: wel of niet uit flash memory. 

Zoals eerder vermeld, is er een tijd geweest dat we werkten met component tests op de televisie, 

waarbij iedere component was ingebed in zijn eigen executable: het test-skeleton. Deze methode 

bleek dermate onderhoudsgevoelig dat we ermee zijn gestopt. Een belangrijk deel van onze 

component tests worden uitgevoerd in één executable: het platform test-harness. Slechts enkele tests 

worden uitgevoerd op de PC, in een eigen test-harness, voor tests die uitgevoerd kunnen worden 

zonder TV hardware. 

1.4.11 Tools 

Behalve de software die moet worden uitgevoerd in een televisie, zijn er nog allerlei tools. 

● Koala en de MIDL zijn reeds genoemd. 

● Voor elk van de 3 soorten processors is er een C cross compiler/linker, in ieder geval 

voor voor de MIPS is er een debugger. Ook wordt gebruik gemaakt van een native 

compiler op de desktop of laptop, om componenten te testen en voor de tools die lokaal 

draaien. Verder wordt er gebruik gemaakt van een aantal script talen zoals perl. 

● Er is software gebruikt om C files te controleren op foute constructies, en overtredingen 

van coderingsregels. De static analyser die ik heb meegemaakt was QA-C. 

● Er is een flow-charter voor het tekenen van structuur diagrammen (Microsoft visio) 

● Er is software om vanaf een PC de registers in de TV te lezen en te schrijven. 

● Er is een installatie tool om de software op de tv te installeren en te onderhouden, en 

een script op de PC om deze software te verzamelen. 

● De software op de TriMedia's wordt uitgevlooid en getest met hulp van softwareinstrumentatie. 

Om het realtime ritme te handhaven print men niet méér dan voor de 

analyse noodzakelijk is, en past men een compressie techniek toe op de gegevens die 

gelogd worden. Hiervoor wordt gebruik gemaakt van een pre-compiler op de PC, en 

een tool dat binaire nummers in de log-file vervangt door tekststrings, en het resultaat 

converteert naar een excel file. 

● Er is capture software om gegevens uit de audio en video stromen zichtbaar te maken 

● Er is een tool om een test-harness te genereren bij een Koala component. Vanaf een PC 

kan men dank zij RPC toegang krijgen tot een component die draait op de MIPS via 

Pagina: 41 / 230


1 Inleiding 


een koala of com interface. Het generatie tool genereert stubs voor de MIPS software, 

en symbol files voor een programma op de PC dat test-scripts kan uitvoeren, en een 

testrapport genereert. Het generatie tool genereert ook menu's om interface functies aan 

te roepen met behulp van de afstandsbediening. 

● Er is een programma op de PC dat het NVM (non volatile memory) kan lezen en 

schrijven 

● Time-doctor wordt gebruikt. 

● Er is software voor het specificeren van gebruikers menu's. 

● Er is software om remote controls aan te sturen vanaf een PC. Er is software om vanaf 

een PC pattern generators aan te sturen e.d. 

● Waarschijnlijk ben ik niet volledig. 

Veel van deze programmatuur wordt verstrekt door derden, sommige tools zijn home-made van 

NXP, en sommige zijn home-made van onze klant. Vaak is er een overlap van programma's die 

gemaakt waren voor persoonlijk gebruik, en later tot handig tool voor allen werden verordend. Ook 

is er overlap omdat een klant een eigen programma hanteert en NXP ook een tool beschikbaar stelt. 

Soms gebruiken de hardware ontwerpers andere gereedschappen dan de software ontwerpers. 

In de praktijk kan men zich niet altijd houden aan zijn eigen methode en gereedschappen. 

Bijvoorbeeld bij een probleembeschrijving hoort een beschrijving van het scenario dat leidt tot het 

probleem, en een beschrijving van het waargenomen fenomeen. Deze beschrijvingen refereren aan 

de gebruikte gereedschappen, hun invoer en hun uitvoer. De ontdekker van het probleem en de 

oplosser moeten allebei het gebruikte gereedschap kennen. 

1.4.12 Version control 

Momenteel (2004-2008) wordt binnen NXP een Version Control system (Continuous / 

Synergy) ter beschikking gesteld, waarin voldoende software is opgenomen voor een platform 

build. Software voor een product build wordt beschikbaar gesteld in een folder op een shared disk. 

Hier worden door de build manager recente generaties bijgehouden, compleet met product binaries 

(executables). Dit betreft zowel optimized binaries als ook debug binaries, en een tussenvorm 

waarin slechts ingebouwde “asserts” worden getest. In deze product info-trees mag je niet wijzigen, 

als je wilt wijzigen dan moet je een lokale kopie maken. Met deze constructie hoopt men de 

synchronisatie-tijd en de build tijd voor ontwikkelaars enigszins te reduceren. Koala doorzoekt de 

gehele folder tree tijdens een build, hoe kleiner de tree hoe sneller de build, vandaar dat de folder 

structuur in het revision control system getrimd is voor platform (test harness) builds. 

Ieder team heeft zijn eigen centrale revision control systeem, Daarin komen alle benodigde 

packages, ook die van andere teams. In ieder package is ieder project een branch. Zo is er ook in 

iedere folder en iedere file een branch per project. De baselines van packages van andere teams 

worden overgenomen met behulp van DCM (distributed configuration management), en het eigen 

package wordt verstuurd met behulp van DCM. Iedere branch kan subbranches hebben die later 

weer met elkaar vergroeien tot main-branch, als de versions van de tips gemixt worden tot een 

resulterende version. Package versions en folder versions bevatten een set elementen. Als de set 

veranderd wordt een nieuwe version gemaakt van de folder. 

Pagina: 42 / 230


1 Inleiding 


1.4.13 Instrumentation 

Vlak voor ik met pensioen ging werd een ontwikkel-omgeving gepresenteerd voor MIPS software, 

Pagina: 43 / 230 

main.c sub1.c sub2.c 

#include 

#include 

extern void fsub1(void); 


int main(int argc, char *argv[]) 

{ 

int i; 

/* normally an endless loop */ 

for (i=0; i build product,optimize 

••• 

••• 

••• successfully ••• 

C:> touch sub1.c 

••• 

••• 


C:> build product,optimize,ENABLE_PRINT 

••• 

••• 


C:> 

Een manier om sub1.c te laten loggen. 

#include 

#ifdef ENABLE_PRINT 

#define PRINT(p) printf p 

#else 

#define PRINT(p) 

#endif 

void fsub2(void) 

{ 

static int c=2; 

static int d=3; 

/* obtain c */ 

c++; 

PRINT (("c = %d\n",c)); 

/* obtain d */ 

d++; 

PRINT (("d = %d\n",d)); 

} 

main.c sub1.c sub2.c 

#include 

#include 



int main(int argc, char *argv[]) 

{ 

int i; 

/* normally an endless loop */ 

for (i=0; i


1 Inleiding 


waarin een debugger ontbrak. Later werd GDB gepresenteerd als debugger. Deze debugger is 

beschreven in een erg dik handboek, en er was een half A4-tje waarin werd uitgelegd hoe je vanaf 

een PC software in een televisie kon debuggen. Inmiddels werd op grote schaal gebruik gemaakt 

van logging (instrumentatie), dat voor de TriMedia software reeds standaard was. Ondertussen 

waren de voordelen ontdekt: test-werkplekken kunnen beter gedeeld worden met kort lopende 

sessies waarin gegevens in een log-file geplaatst worden. Sessies met een debugger houden een testwerkplek 

langdurig bezet. De debugger werd slechts zelden gebruikt. Er zijn wel regels voor het 

wel of niet gebruiken van instrumentation. Nadat je het hebt gebruikt voor debugging moet je de 

logging uitschakelen, en verifiëren of de software zonder logging correct is. De software moet 

worden overgedragen, zonder werkende logging. 

Dit laatste is niet helemaal waar. Sommige boodschappen werden geacht nuttig te zijn voor allen, of 

in ieder geval velen. Er is daarom een categorie console messages die getoond worden in “assert” 

mode, maar de gewone console messages worden adhoc ingebouwd of naar behoefte geactiveerd. 

Instrumentatie wordt gebruikt voor een aantal redenen. Zonder garantie dat de redenen uitputtend 

zijn opgesomd geef ik de volgende: 

controle op volledigheid bij het testen (coverage) 

frequentie meting en doorlooptijd-tijd meting ten behoeve van tijd optimalisatie 

loggen ten behoeve van debugging en testen (white-box tests) 

signaleren van overtreding van preconditions, postconditions en invariants, met behulp van “assert” 

Alleen om de laatste twee redenen wordt instrumentatie gebruikt in de MIPS software. Logging en 

assert zijn rechttoe rechtaan “met de hand” ingebouwd, zonder generator, of aspect oriented 

programming. 

1.4.14 Slot opmerkingen 

Alles stroomt 

Wat opvalt is dat er veel verhuisd en geherstructureerd kan worden: 

Er wordt verhuisd tussen besturingsniveau en transformatie niveau (wel/niet delegeren) 

Oplossingen verhuizen van Koala componenten naar COM componenten 

Het binden van diversity parameters worden verhuisd van compilatie-tijd naar uitvoerings-tijd visa 

versa 

Er wordt verhuisd in de folder en package structuur 

Executie wordt verhuisd van de éne prioriteit naar de andere 

Een oplossing kan zelfs worden verhuisd van uitvoerings-tijd naar ontwerp-tijd of omgekeerd. 

Er wordt waarschijnlijk veel tijd aan herstructureren en verhuizen besteed, ik weet niet goed hoe je 

het kunt vermijden, maar ik weet wel dat dit werk is dat niet direct leidt tot vooruitgang. 

Waarschijnlijk is het werk dat bijdraagt aan de perioden waarin niets lijkt te gebeuren in 

“Weinberg's Law of Twins”. Echte voortgang, dat zijn de krenten in de pap, maar de krenten kunnen 

de pap niet missen. Wil je dat meer progressie zich manifesteert, dan zou je dat misschien kunnen 

bereiken door het verhuizen en herstructureren te beperken of te verbieden. Maar de structuren die 

er zijn worden dan misschien een keurslijf, waar nogal wat work-around overheen puilt, zoals 

bijvoorbeeld met Horcom is gebeurd. Let wel, vaak is er eerst de work-around, en dan pas het 

inzicht dat herstructureren misschien beter zou zijn geweest. Daarna kan er pas geïnventariseerd en 

beslist worden over opnieuw doen. In actuele situaties geldt vaak: “het zit er al in en het werkt”. 

Pagina: 44 / 230


1 Inleiding 


Maar bij een nieuw project zou je elke keer kunnen beginnen met het opruimen van enkele uit de 

hand gelopen constructies. 

Door te herstructureren ben je bezig met de stuff en blijf of ga je de problematiek beheersen. Net als 

koffie drinken, kletsen met een collega, en opruimen, kun je het doen, als je het even niet ziet zitten 

of een beslissing wilt uitstellen. Sommige mensen zeggen dat mensen herstructureren om een stukje 

van zichzelf vast te leggen in hun omgeving, of in ieder geval om de omgeving naar hun hand te 

zetten, zodat ze zich er thuis voelen. Als de law of twins geldt, dan heb je herstructureren nodig om 

op een gegeven moment door te stoten, en is het te vergelijken met (lang) mikken voordat je schiet. 

“Weinberg's Law of Twins”: eigenlijk geldt hier: Wie een parel wil zien moet er zelf maar naar 

duiken. Maar ik zal toch maar een referentie geven. Ik vond de wet in Wikipedia (Engels). De 

verwijzing die daar bij staat: “Weinberg, Gerald M. The Secrets of Consulting: A Guide to Giving 

and Getting Advice Successfully, Dorset House Publishing Company, 1986. ISBN 0-932633-01-3" 

Grenzen van een revision control system 

Versies van files, die direct of indirect uit elkaar voorkomen vormen in een klassiek RCS een DAG 

(Directed Acyclic Graph) Er is de aanname dat de versies ervan op een gestandaardiseerde manier 

elkaars wijzigingen kunnen overnemen (met een merge programma), en dat zo wijzigingen in de 

éne branch gemakkelijk kunnen worden overgenomen in een andere. NXP rekt dit idee op en 

veronderstel dat wijzigingen in het ene lid van een product familie op gestandaardiseerde manier 

kunnen worden overgenomen in een ander. Maar het zou kunnen dat er zoveel is gewijzigd tussen 

producten (zie ook het voorgaande: “alles stroomt”) dat dit niet meer volledig opgaat. De praktijk 

moet uitwijzen of er nog een zinvol deel overblijft voor de gestandaardiseerde 

gegevensuitwisseling. In het verleden bleek vaak dat dergelijke uitwisseling zinvol is tussen redelijk 

verwante leden, en dat uitwisseling zinvol is tussen dat deel van de code dat nauwelijks gewijzigd 

is. 

In het voorgaande: “alles stroomt” worden ontwikkelingen geschetst waarvan de herstructurering 

niet vastligt in de structuur van een version of revision control system. Al zijn de resultaten van 

dergelijke ontwikkelingen wel over te dragen met standaard merge, copy en delete, toch herken je 

de herstructureringen meestal niet door puur naar de ontwikkeling van een branch te kijken. Alleen 

naamswijzigingen en verplaatsingen in de folder structuur worden immers geregistreerd als 

herstructureringen. 

Ontwikkel methoden 

Bij NXP waren ontwikkelmethoden een beetje een verwaarloosd. Voor je met coderen begint 

moeten de interfaces beschreven zijn en moet er een component description zijn. Deze 

beschrijvingen zijn echter meer implementatie en gebruikers handleidingen dan ontwerp 

documenten. In het begin moest er een Visio plaatje (schema) gemaakt worden van een component, 

later werd het plaatje gegenereerd uit de cd file. Er is geen voorschrift om een ontwikkel traject te 

doorlopen dat eindigt met de juiste componenten en interface structuur. Het enige dat er is is een 

plaatje met blokken: applicaties, middleware, operating, platform en dergelijke en heel misschien 

een aanduiding waar de clients zitten waar de servers ervan. Niet echt refutable stuff, meer een 

hoofdstuk indeling. 

Dit haalde het niet bij de stappen (acht of zo) in ORM, die allen een model opleveren. En ook niet 

bij de UML schema's waarmee fasen en facetten van het object georiënteerd ontwerpen worden 

beschreven. Al evenmin bij de tweedeling probleem beschrijving en probleem oplossing bij de 

Pagina: 45 / 230


1 Inleiding 


"problem frames"van Michael Jackson. Nu we leven in een tijdperk van hergebruik en onderhoud 

van het bestaande is het mogelijk lastig om te spreken over ontwikkelfasen, en beter om te spreken 

over een aantal modellen die je bijhoudt. Misschien doe je dat per project toch ongeveer in een 

bepaalde volgorde. 

Zonder echte ontwikkel methoden, begin je misschien al te snel te programmeren als je een idee 

hebt of de weg ziet naar een oplossing. Methodiek zou het idee moeten vervolmaken, integreren, 

mogelijk weerleggen, herstructureren, of weer ideeën uitlokken. Een methode is de transpiratie na 

de inspiratie. 

Aangezien de werkwijze van NXP leidend is bij mijn ontwerp van een revision control systeem is 

de invloed van het volgen van een ontwikkelmethode minimaal. Toch stel ik mij voor dat 

hergebruik in product families leidt tot kleine reeksen bewerkingen van model onderdelen. Op zijn 

simpelst: eerst wijzig je een schema, dan een document, dan een testscript, en dan een source 

module. Op enig moment is een deel van zo'n ontwikkelreeksje klaar, en is er een rest deel te gaan. 

Omdat oplossingen ontstaan in wisselwerking tussen kennis “intern in het hoofd” en ”extern in de 

modellen”, is de volgorde waarin de (extern buiten het hoofd) modellen worden bijgewerkt 

boterzacht. Bovendien zijn er allerlei confrontaties (in gebruik nemen, reviews, tests) die tot 

volgorde afwijkingen kunnen leiden. De toestand van zo'n reeks wordt bepaald door wat is 

afgevinkt als klaar, en dat is niet altijd aaneengesloten, en startend met de eerste volgens de formele 

volgorde. De toestand van het product wordt dan bepaald door de toestanden van de reeksjes. 

Alleen al door te spreken over “de toestand van het product” lijkt dit een onderdeel van 

configuration management, en zou je na moeten gaan wat de bijdrage van een version control 

system zou kunnen zijn. Maar niet in dit schrijfsel dus: mijn werk bij NXP leverde onvoldoende 

use-cases. Vaak werden document, source code en testscript gezamenlijk gewijzigd en 

overgedragen. Alleen bij echte nieuwbouw was sprake van acceptatie procedures met min of meer 

harde volgorden. 

Het idee van de wisselwerking tussen kennis in het hoofd en kennis in de wereld vond ik in de 

Nederlandse versie van: “Donald Norman, “The Psychology of Everyday Things”, vertaling: Prof. 

dr. A.J.W.M Thomassen, Dictatuur van het design, A.W. Bruna Uitgevers B.V. Utrecht, 1990 ISBN 

90 229 7907 5 

Een voorbeeld. Een uiterst simpel fictief ontwikkelingsmodel. Er moet een flow diagram ontwikkeld 

worden. De drie ontwikkel fasen zijn: eerst bepaal je de blokken, dan de verbindingslijnen, en 

tenslotte de teksten. Tijdens een nieuwe ontwikkeling wordt strikt volgens deze methode gewerkt. In 

de repository zie je dan ook eerst versies met alleen blokken, dan is er een mijlpaal, (een “hoera 

snapshot” zeg maar), en daarna komen er versies met blokken en lijnen, en tenslotte komen er 

versies waarin ook teksten staan. De diagram versies die gemarkeerd zijn met een mijlpaal worden 

als waardevolle modellen beschouwd, met bestaansrecht vanwege de informatie die ze 

benadrukken. 

Reeds in de tweede fase, als er lijnen getrokken worden zie je dat soms blokken verschijnen, 

verdwijnen, of verplaatst worden, en in de derde fase kunnen er ook correcties optreden op blokken 

en lijnen. En tenslotte wordt er onderhoud gepleegd op het uiteindelijke resultaat, met wijzigingen 

op alle ingrediënten. Een “reversed engineering” tool zorgt ervoor dat uit een volledige versie een 

model met uitsluitend blokken, en een model met blokken en lijnen gemaakt wordt. De modellen die 

Pagina: 46 / 230


1 Inleiding 


gemaakt worden met het reversed engineering tool zijn geen “source code”. In een source code 

revision control systeem horen ze strikt genomen niet voor te komen. Up-to-date zijn daarin dus op 

een gegeven moment uitsluitend volledige schema's, en verouderd zijn daarin de schema's met 

alleen blokken, en de schema's met blokken en lijnen. Zelfs als je de reversed engineering modellen 

opneemt in de repository dan zijn het versies van een andere file dan de source file. Eigenlijk zijn 

de blokken modellen ook geen versies van elkaar, omdat ze niet door update uit elkaar voortkomen. 

Je zou ze in de repository willen plaatsen zodat ze beschikbaar zijn voor mensen die niet over het 

tool beschikken, bijvoorbeeld omdat ze in een ander team werken. 

Conclusie: voor een volledige verzameling use-cases voor een repository zou je een aantal 

ontwikkelen onderhouds- methoden moeten beschouwen. 

Use-cases die voortkomen uit ontwikkel methoden zullen soms leiden tot een regel voor het gebruik 

van een repository, soms tot een requirement voor de repository, en soms tot een verzoek tot 

aanpassing van de tools van de ontwikkel methode. Het bovenstaande leidt bijvoorbeeld tot de 

regel: Zodra een mijlpaal is gepasseerd pas je reversed engineering toe en plaatst het resultaat in 

een nieuwe file in de repository. Het wordt van die file de eerste versie. Een requirement voor de 

repository: files die geen source file zijn moeten gefaciliteerd worden. Een voorstel om details van 

een ontwikkelmethode aan te passen: zie het volgende voorbeeld. 

Een tweede voorbeeld. In de jaren negentig heb ik gewerkt met een IDE voor het maken van C 

code. Deze IDE bevatte een “wizard” voor het generen van initiële C source code voor een aantal 

soorten applicaties. Er zijn bijvoorbeeld DOS command line applicaties, ActiveX applicaties, MFC 

applicaties COM applicaties en dergelijke. De wizard leidt je door een menu en genereert dan een 

aantal files met initiële code. Deze files bevatten vaak een “comment” regel waarin iets staat als 

“insert here your code:”. Het hele gegenereerde kun je beschouwen als source code. Op een 

gegeven moment ontdekte ik dat je het process kunt herhalen, zelfs als je eigen code al hebt 

ingevuld, en je de applicatie hebt uitgebreid met allerhande eigen files. Bij dit herhalen kun je 

andere opties en waarden opgeven: je kunt ze onderhouden. Blijkbaar worden de oorspronkelijke 

menu keuzen en velden in de wizard met reversed engineering gereconstrueerd uit de gegenereerde 

code, zodat je het menu kunt aanpassen, waarna opnieuw initiële code wordt gegenereerd, die 

daarna in het geheel de oorspronkelijk gegenereerde code vervangt. Bij bepaalde soorten 

applicaties was het genereren ook nog eens modulair, en complex: bijvoorbeeld voor elk menu kon 

je de wizard aanroepen, of voor elk window. 

Als je daar met mijn ogen naar kijkt, en misschien ook als je ernaar kijkt met de ogen van een 

configuration manager, dan kom je tot het volgende: de keuzen en de ingevulde velden in de menu's 

van de wizard zijn samen de source code. Deze code zou je liefst sec willen opslaan in de repository 

in één of meer files, en eventueel terug halen in de wizard voor bewerking. Door ze in source files 

op te nemen zijn de opgegeven keuzen en waarden “identificeerbaar” geworden. De gegenereerde 

files zijn geen source en moeten liefst niet gemengd worden met source code. Dus geen comment: 

“/* plaats hier uw code: */” maar in plaats daarvan “#include ”. Dit zijn typisch 

aanpassingen in de details van deze minimale? “ontwikkelmethode”. 

Onder omstandigheden wil je misschien het genereren uitstellen en daar een build procedure voor 

gebruiken, in plaats van de instant generatie van de wizard. 

Het zal voorstelbaar zijn dat het wijzigingen van de parameters en opties dikwijls geen 

“standalone” wijzigingen zijn, vaak moet ook de eigen code aangepast worden. 

Pagina: 47 / 230


1 Inleiding 

1.5 Televisie, de hardware 


Voor ons bestaat een televisie uit een kabinet, met daarin een LCD of plasma scherm met 

toebehoren, een voeding, een infrarood oog, en een paar luidsprekers, en uit een PCB (printed 

circuit board), soms twee PCB-'s, en een enkele keer drie. Het main-board bevat de tv chip van 

NXP, een tuner, een channel decoder, flash memory, (onverslijtbaar) NVM, chips van klanten, in - 

en uitvoer pluggen, een houder voor een CI-card enzovoort. Het tweede board bevat pluggen voor 

de zijkant of de voorkant van de TV. Zelden wordt er door een klant gebruik gemaakt van een “bolton” 

board, met extra hardware. Het kan gebeuren dat een main-board combineerbaar is met 

meerdere side-boards, of een side-board met meerdere main-boards. Bij een boardset horen 

uiteraard connectors en kabels om de boards onderling te verbinden, en om ze te verbinden met het 

kabinet. 

Zo'n board of boardset is een reference boardset als het gemaakt is door NXP of een design-in 

boardset als het gemaakt is door een klant. 

De boardset is vaak combineerbaar met meer dan één type kabinet, en een kabinet is vaak 

combineerbaar met meer dan één type boardset. 

Soms moet er geïmproviseerd worden: dan wordt er bijvoorbeeld een externe voeding gebruikt om 

de boardset van stroom te voorzien, of de uarts moeten elektrisch compatibel gemaakt worden met 

de com poorten van de PC. 

Sommige boards zijn niet volledig uitgevoerd, er missen pluggen, of sommige verbindingen staan 

niet op het board. Zo'n board is dan slechts bruikbaar voor een deel van de software tests. Af en toe 

kan het hardware team de functionaliteit van zo'n board uitbreiden. 

De chips op de boards hebben een versie nummer. Tijdens de duur van een project kan worden 

overgegaan naar een boardset met verbeterde chips, of naar een verbeterde boardset. “Software 

Diversity” wordt gebruikt om de overgang mogelijk te maken. De “workarounds” voor de oude 

versie kun je dan met diversity uitschakelen voor de nieuwe versie van de boardset. 

Soms als een project net is opgestart, en er nog geen eigen design-in boardset beschikbaar is, 

behelpt men zich met een boardset die er op lijkt. 

Het is zo dat adequate hardware niet altijd beschikbaar is op het moment dat software ontwikkeld 

wordt. Vaak worden tests dan uitgesteld tot een later stadium. Dan bestaat het team vaak uit minder 

software ontwikkelaars (vaak ook anderen), en meer testers. 

Invoer en uitvoer pluggen van een boardset: 

● Antenne (invoer) 

● Scart (invoer/uitvoer analoog video en audio, meestal 2 of drie, op een Europese tv) 

● Cvbs cinch (één voor invoer, één voor uitvoer analoog video) 

● Yc S-VHS connector (één voor invoer en één uitvoer analoog video) 

● sound left/right cinches (enkele voor invoer , één voor uitvoer analoog audio) 

● analoog mono sound input 

Pagina: 48 / 230


1 Inleiding 


● headphone plug (uitvoer analoog audio voor koptelefoon) 

● YpbPr of RGB cinches (één of twee sets invoer analoog video YPbPr: 3 cinches, RGB 5 

cinches) 

● VGA (invoer analoog RGB signaal, PC monitor signaal) 

● Spdif (één of twee invoer één uitvoer digitaal audio niet gecomprimeerd, soms extra een 

optische invoer of uitvoer) 

● Hdmi (meerdere invoer digitaal audio en video niet gecomprimeerd) 

● Dvi (invoer digitaal video niet gecomprimeerd, PC monitor signaal) 

● Usb (invoer digitaal audio, foto, video, gecomprimeerd. Ook wordt usb gebruikt voor 

programmatuur die door installatie tool wordt geïnstalleerd op flash memory) 

● Ethernet (Interactieve communicatie, mail, digitaal audio, foto, video, gecomprimeerd, 

enzovoort) 

● Houder voor een CI (common interface) cartridge waarmee een abonnement op pay-tv 

stations kan worden gerealiseerd. 

● UART (een van de uarts wordt gebruikt om de standby processor te programmeren, de 

andere om een console verbinding met de MIPS te realiseren) 

● JTAG (deze invoer/uitvoer is verbonden met een probe die via het local area netwerk is 

verbonden met een PC. Via JTAG kan logging informatie van MIPS en TriMedia naar een 

PC worden gestuurd, kan programmatuur worden geladen in MIPS of TriMedia, worden 

registers gelezen of geschreven, wordt geheugen bekeken of gewijzigd, breakpoints gezet of 

verwijderd, en dergelijke. 

● Connector infrarood sensor (afstandsbediening) 

● Connector voor aansturen scherm 

● Connector voor aansturen speakers 

● Connector voor voeding 

● Optionele overige aansluitingen bijvoorbeeld: microfoon voor speech-control, zendertje om 

de remote control te laten piepen, en dergelijke 

Pagina: 49 / 230


1 Inleiding 

1.6 De testplek 


In een laboratorium staan lab-tafels. Dat zijn tafels met een extra schap, een transformator als 

elektrische isolatie, een zekering, een hoofdschakelaar, een aard-lek schakelaar, veel stopcontacten, 

en een aard-strip. Deze zijn ingericht als test-plekken. Meestal is een lab-tafel groot genoeg voor 

twee plekken. Zo'n test-plek bevat een televisie voor het testen van software. Bij iedere televisie 

hoort een probe, die bedoeld is om van buiten af geheugens en registers in de televisie te lezen en te 

wijzigen. Behalve de tv is er een desktopcomputer, die met zijn com poorten is verbonden met de 

uarts en met de probe, en mogelijk nog met een signaal generator die te bedienen is met behulp van 

een (test) script vanaf de desktop. Ik zal de computers op de testplek "desktop" noemen om ze te 

onderscheiden van "personal" computers, wat dan weer laptops of desktops kunnen zijn. Testplek 

desktops zijn allemansvriendjes, waar Ms-Windows op draait. 

Desktop en probe zijn ook verbonden via het intranet; het IP adres van de probe kan worden 

gelezen via een com poort. De probe is verbonden met de JTAG plug van de tv. 

De test desktop bevat veel gespecialiseerde tools die normaal niet op een bureau PC aanwezig zijn: 

een debugger, een tool om het NVM te lezen of te schrijven, om registers te lezen of te schrijven, 

om test scripts uit te voeren, om programma's en configuratie files over te brengen naar de tv, 

drivers voor afstandsbediening en voor patroon generators die aangestuurd worden via com poorten 

of USB en dergelijke. 

Er staan DVD spelers, die verbonden zijn met invoer pluggen, en een kleine analoge tv die 

verbonden is met een analoge uitvoer-plug van de tv. Op sommige tafels staat een home cinema set, 

die verbonden is met de spdif uitvoer. De antenne plug is verbonden met één van de interne 

televisie-netwerken van het laboratorium, met een patroon-generator, of met een mobiel tv 

stationnetje, dat analoog of digitaal uitzendt. Andere invoer pluggen zijn mogelijk ook verbonden 

met patroon-generators. Meestal is er een koptelefoon. Er zijn afstandsbedieningen voor de tv en de 

dvd spelers. Af en toe wordt een video recorder gebruikt, of is een canal-plus decoder verbonden 

met een scart. Er is een afstandsbediening op een voetstuk, die aangestuurd wordt via een 

com-poort van de desktop, en software die zo'n afstandsbediening aanstuurt. Incidenteel wordt een 

spelcomputer aangesloten, en soms is er een set met een settopbox. 

Vaak is er enige afscherming om te zorgen dat je elkaar niet stoort met een remote control. 

Kern van een werkplek zijn altijd de tv, de desktop, de probe, een dvd speler, een monitor, en twee 

afstandsbedieningen (één voor de tv en de monitor, en één voor de dvd speler). De andere 

apparatuur blijft korter of langer, al naar gelang de behoefte. Werkplekken die in gebruik zijn voor 

dagelijkse testen en overdrachtstesten, hebben een grotere kern van randapparaten. Ook 

werkplekken die specifiek zijn opgezet voor audio tests hebben een grotere kern. Een werkplek 

blijft meestal voor langere tijd ingericht met dezelfde televisie. 

Vaak zijn test-werkplekken niet persoonsgebonden en vaak zijn ze ook niet taak gebonden. Ze 

worden gedeeld door testers en ontwikkelaars. Dikwijls werkt een persoon of een team voor meer 

dan één project, en heeft dan zeker te maken met meer dan één test-werkplek. Meestal zijn er 

diverse tv's nodig binnen één project, bijvoorbeeld om te testen met verschillende kabinetten, of 

verschillende boardsets. 

Soms is het niet nodig om beeld of geluid waarnemingen te doen, of om pluggen in en uit te 

Pagina: 50 / 230


1 Inleiding 


trekken, of apparaten aan en uit te zetten, een keuze menu te volgen op een dvd speler enzovoort. 

Dan wordt een tool als VNC gebruikt om vanaf je bureau de test desktop over te nemen en een test 

uit te voeren. Ook wordt dit tool dikwijls gebruikt als iemand aan zijn bureau uitzicht heeft op de 

testplek, zodat beeld en geluid gewoon kunnen woeden waargenomen. 

Af en toe wordt er een opstelling gemaakt met een webcam zodat iemand werkelijk remote tests kan 

uitvoeren. 

Veel van de hulp-apparaten zijn “signaal generators”. Dit geldt bijvoorbeeld al voor de DVD 

spelers. Bij een signaal generator horen “signalen”, voor de DVD speler zijn die afkomstig van 

dvd's. Voor patroon generatoren zijn dit patronen. De eenvoudige patroon generatoren bevatten een 

ingebakken hoeveelheid patronen, maar de meeste zijn programmeerbaar. Tv zendertjes moeten iets 

uitzenden. Er is dan ook een uitgebreide collectie aan patroon bestanden en multimedia bestanden 

beschikbaar op enkele file servers, en er zwerft een uitgebreide collectie dvd's door de lab ruimtes. 

Toen ik er wegging was blu-ray sterk in opkomst en werd er nog nauwelijks met video recorders 

getest. Alleen als specifieke video recorder problemen moesten worden opgelost, zoals variabele 

lijn en beeld frequentie, werd de recorder uit de kast gehaald. 

Pagina: 51 / 230


2 Schets van het revision control system 



2.1 De basis 

In de zeventiger en tachtiger jaren had ik toegang tot de ICT bibliotheek van Philips Eindhoven. 

Hier hadden ze een kopie-service, waarbij ze maandelijks een blad met uittreksels distribueerden 

van tijdschrift-artikelen. De artikelen die je interessant vond kon je aankruisen, waarna ze een kopie 

van het artikel toestuurden. Zo heb ik in die tijd een klein persoonlijk archief opgebouwd van 

tijdschrift artikelen. 

Eén van die artikelen was “Update Reconsidered” van Ben-Michael Schueler. (Gepubliceerd in 

“Architecture and Models in Database Management Systems” G.M. Nijssen, (ed.), North Holland 

Publishing Company, 1977). Hierin wordt een lans gebroken voor opslag methoden waarbij niets 

wordt weggegooid. De methode om een oude waarheid te vernietigen door deze te overschrijven 

door een nieuwe wordt “Aton update” genoemd, de methode om diskruimte opnieuw te gebruiken 

omdat de file die er stond niet meer interessant is wordt “Palimpsest” genoemd, en het per ongeluk 

kwijtraken van informatie “Alexandria update”. Wie niet beschikt over het artikel kan de oorsprong 

van deze benamingen toch wel achterhalen, denk ik. Al deze updates zijn fout, we zouden geen 

informatie mogen weggooien, of kwijtraken. Voor mij was dit artikel een eye opener. Maar het was 

ook een intellectuele uitdaging, die ik met een voorbeeld niet tot een goed einde bracht. Dit 

schrijfsel is dus een herkansing. 

Recente artikelen over temporele databases zijn gemakkelijk te vinden dank zij Google; enkele 

gevonden namen: “Christian S. Jensen", "Richard T. Snodgrass", artikelen die ik ooit van hen las: 

“2 Semantics of Time-Varying Information”, “Introduction to temporal database research”. Hierin 

wordt onderscheid gemaakt tussen “valid time” en “transaction time”. 

Stel bijvoorbeeld dat ene Jansen leefde van 1933 tot 2003, dan is de periode 1933-2003 de “valid 

time”, die begrensd wordt door twee gebeurtenissen (events), één in 1933 en één in 2003. Zelf ben 

ik geboren in 1944. Stel nu dat ik in 1983 hoorde dat hij in 1930 geboren was, en in 1995 hoorde ik 

dat hij in 1933 geboren was, en in 2007 dat hij in 2003 overleden was. Nu is er een “transaction 

time” over de periode 1944-1983, één gedurende 1983-1995, en één gedurende 1995-2007, en één 

van 2007 tot heden, met gebeurtenissen in 1944,1983, 1995 en 2007. Dank zij het feit dat ik de hele 

situatie zelf bedacht heb, hebben we een totaal overzicht dat leidt tot het volgende: gedurende 

1944-1983 was mijn kennis nihil, in de periode 1983-1995 fout, daarna 1995-2003 correct, dan in 

2003-2007 verouderd, en tenslotte correct. Zonder totaal overzicht hebben we alleen de transacties: 

in plaats van 'fout' kunnen we achteraf zeggen 'vermoedelijk fout', en in plaats van 'correct' kunnen 

we slechts zeggen 'vermoedelijk correct'. Er kan altijd een transactie plaatsvinden die onze kennis 

omtrent het valid zijn aanpast. 

Onzekerheid of het revision control systeem actueel is, is er meestal niet, een transactie wijzigt 

zowel het revision control system (de werkelijkheid) als ook de kennis die het revision control 

system over zichzelf heeft. Die kennis over zichzelf is dus best wel actueel. Tenminste, als de 

revision control software geen fouten bevat, de hardware betrouwbaar is, het geheel goed is 

Pagina: 52 / 230



2.1 De basis 

beveiligd, de administrator foutloos werkt enzovoort. 

Wat verwacht ik van een revision control systeem? 

● Het revision control system is vooral nodig om gestructureerd samenwerken mogelijk te 

maken Als iemand iets beschikbaar stelt voor gebruik door een ander, dan moet een 

bepaalde kwaliteit gegarandeerd zijn. Er is dus software die voldoet aan een kwaliteitseis, en 

software die niet voldoet maar daar naar op weg is. In ieder stadium is er een gebruikersclub. 

Voor iedere club is er een reden om de software te gebruiken, en kunnen er regels zijn 

voor het gebruik. Voor al die software is er het revision control system. 

● Dan is het revision control system er ten behoeve van review, reconstructie van wat er is 

gebeurd, analyse en debugging: om de software op peil te houden of te verbeteren dus. 

● Verder voor (project) evaluaties en dergelijke. Om de werkwijzen te verbeteren dus, en 

misschien ook om verantwoording af te leggen betreffende werkwijze en product. 

● Tenslotte is er het opportunistische argument: je weet nooit waar het goed voor is. 

In ieder geval voor de laatste 3 items van de verwachting geldt dat het revision control system 

antwoord moet kunnen geven op wie wat waar wanneer vragen over de inhoud van de repository. 

Zo nauwgezet mogelijk moet alles vastgelegd worden. 

Gestructureerd samenwerken wat is dat? De belangrijkste voorwaarde is dat er een taakverdeling 

mogelijk is, waarbij de taken min of meer onafhankelijk van elkaar worden uitgevoerd. Iemand 

maakt iets, draagt het over, en pas daarna kan een ander er kennis van nemen of het gebruiken, of er 

verder aan werken. Dit hoeft niet per se één persoon te zijn: een groepje personen maakt iets, … 

Voor zaken als overleg, brainstormen, over de schouder meekijken, met zijn drieën samen en 

tegelijk aan een document werken, biedt deze repository geen faciliteiten, en moet je zoeken naar 

andere middelen. Moderne web applicaties en elektronische hulpmiddelen kunnen helpen, als dit 

soort samenwerken nodig is tussen mensen die geografisch gescheiden zijn. Maar de bijdrage van 

het software archief is hier praktisch nihil. 

Veel version control of revision control systems zijn source code revision control systems. Ik zal 

proberen te komen tot een software revision control system, Het liefst een beetje in de richting van 

een software project revision control system. 

Allereerst is er een naam nodig voor de software die ik beschrijf. Zeker als ik toekom aan 

importeren en exporteren is het nodig om export naar een ander systeem te onderscheiden van 

export naar een systeem dat dezelfde software gebruikt. 

Software ontwikkelen is als het gezamenlijk beklimmen van een berg, je klimt een eindje en dan 

kan een ander de aangebrachte voorzieningen gebruiken, Zelf gebruik je de voorzieningen die 

anderen aanbrengen om weer een nieuw stukje te klimmen. Dit geldt voor medewerkers binnen een 

team en ook tussen de teams. 

Ik vond geen woord voor “klimmen in een bepaald verband”, en dus zal het voorlopige codewoord 

voor de SCM software zijn: “Klimverband”. Maar de termen die ik hanteer zijn Engels. Dan wordt 

dit “Climb-Connexion” of kortweg :”Climbexion”. 

Pagina: 53 / 230



2.2 Begrippen 

2.2 Begrippen 

2.2.1 Basisstructuur 

Allereerst definiëren we een timestamp. In C en C++ is er een standaard functie 

time_t time(time_t *tp) 

Deze retourneert een datum/tijd variabele met een resolutie van één seconde. Dit is enigszins grof 

voor een event. We zullen deze functie inbedden in de functie climbexion_timestamp() die bij een 

aanroep een combinatie van een time en een sequence number retourneert, en die garandeert dat 

ofwel de time is verhoogd sinds de vorige aanroep en het en sequence number geïnitialiseerd, 

ofwel de time is (nog) steeds hetzelfde, maar het sequence number is verhoogd. In de voorbeelden 

in dit hoofdstuk laat ik het sequence number weg. Soms zullen timestamps echter slechts bestaan 

zonder sequence number, bijvoorbeeld, de datum/tijd van de laatste wijziging van een file die door 

desktop software is gewijzigd. Bij gebruik van zo'n timestamp kan Climbexion een sequence 

number toevoegen, voor zover nodig om een unieke identifier te vormen. De transacties die het 

revision control system wijzigen zijn vaak complex. De starttijd van een transactie is een 

timestamp, maar items binnen de transactie kunnen een volgnummer behoeven. Waarschijnlijk kan 

ook hiervoor het sequence nummer gebruikt worden, mits dit niet ten koste gaat van het gebruik van 

de temporele uitbreidingen van de database. 

Software bestaat uit files, die in een drawer zijn verzameld. Drawers hebben een folder structuur, de 

files staan in de folders. Een file staat op een willekeurig moment slechts in één folder. Een drawer 

is gealloceerd in een location. Bijvoorbeeld op een server, of op een PC. 

De keuze voor files en folders als identificeerbare elementen in een revision control system is 

redelijk traditioneel. Toch impliceert dit enige regels voor de software die erin is opgeborgen. Een 

software entiteit, bijvoorbeeld een class, een component, een variabele, een procedure, een namespace 

wordt alleen dan geregistreerd en geïdentificeerd in Climbexion als die één op één 

correspondeert met een file, een folder, of een ander Climbexion element. Van te voren dien je te 

bedenken wat je wel en niet samen in een file (of een folder) stopt. 

Het revision control system bevat files. Mutaties wijzigen die files. Deze mutaties wijzigen zowel 

de werkelijkheid (de files) , alsook de kennis (van het revision control system) omtrent die 

werkelijkheid, dus kunnen we het ons gemakkelijk maken: “transaction time” = “valid time”. We 

hoeven alleen maar de valid time te implementeren. Kortom de repository is zijn eigen “universe of 

discourse”. 

Een file kan stadia doorlopen: er is een “course of development” of kortweg een “course”. Er is een 

course van zijn name, van de folder waarin hij voorkomt: de folder reference, en van zijn contents. 

Het bestaan van een file in een drawer: zijn existence kan eindigen, en misschien later weer 

beginnen: er is een existence course. Samengevat: er is een course van de file. De events die de 

course van een file vormen zijn voorzien van een timestamp: de transaction time. Zo'n event is 

bijvoorbeeld een naamswijziging, of een move naar een andere folder, of een gewijzigde inhoud of 

een combinatie ervan. De events van een course zijn bijna altijd “Aton-achtige updates” die een 

Pagina: 54 / 230



2.2 Begrippen 

oude waarheid, een oude realiteit, vervangen door een nieuwe, alleen vergeten we de oude waarheid 

niet met de komst van de nieuwe, we overschrijven niets meer. Het is de “transaction time” die 

maakt dat een “course” een adequate data structuur is, waarvoor geldt: de enige manier om de 

course te wijzigen is een toevoeging aan zijn tip. Een dergelijke toestandswijziging, is ook typisch 

een “valid time” overgang. Iedere toevoeging wijzigt de repository en daarmee ook de 

werkelijkheid. Ik zal ze “successions” noemen. Omdat hier geldt: “transaction time” = “valid time”, 

en we aannemen dat de implementatie van de climbexion betrouwbaar is, daarom is een succession 

onbetwistbaar en behoeft nooit gewijzigd te worden, en ook de timestamp waarmee de overgang 

ingaat wijzigt nooit meer. 

Het revision control system legt verwantschappen vast tussen versies van files, zolang ze uit elkaar 

“voortkomen”. Het legt geen bloedlijnen vast, zodat je in één oogopslag kunt zien: hé die 

eigenschap ven de versie komt van zijn betovergrootmoeder. Ook ontleedt het geen chimaera: als 

functionaliteit verhuist van de ene file naar de andere, dan wordt er geen relatie gelegd tussen de 

file die de functie levert, en de file die de functie ontvangt: een functie is geen geregistreerde een 

entiteit. 

Het wijzigen van names en folder references, zoals dat hier geschetst wordt, lijkt op vrijheid, 

blijheid en anarchie. Je moet hier natuurlijk bedachtzaam, en liefst spaarzaam mee omgaan. In de 

aanloopfase van een programma kan het best wenselijk zijn om namen te wijzigen, en ook tijdens 

fasen van heroverweging, zoals die gelden als je van het ene project overgaat naar het volgende, of 

van de ene chip naar de volgende. Een doel van architectuur is immers om een omgeving te creëren 

waarin mensen zich kunnen oriënteren, en een goede naamgeving en een goede indeling lijken dan 

ook onontbeerlijk, ook al dragen ze niet bij aan een oplossing van het probleem. Om het goede te 

bereiken, moet je soms het minder goede kunnen veranderen. (Nou ja “soms?” Je kunt aan 

verbeteren een heel leven wijden.) 

Pagina: 55 / 230 

File met course



2.2 Begrippen 

Een overeenkomstige file in een andere drawer heeft meestal dezelfde name en staat over het 

algemeen in dezelfde folder, maar hij kan een andere name hebben, en in een andere folder staan, en 

een andere inhoud hebben. Toch zijn deze files verwant. Ik denk dit te realiseren door te stellen dat 

ze tot dezelfde “kin” behoren. Een kin heeft een identificatie. Een file kan niet verhuizen van de ene 

drawer naar het andere. De file vertegenwoordigt de kin in de drawer. Ik denk dat in andere revision 

control systems het begrip trunk het meeste overeenkomt met een kin. Maar een trunk heeft een 

course en een kin niet. Een kin wordt hooguit door één file vertegenwoordigd in een drawer. Deze 

file heeft binnen de drawer een niet wijzigbare identificatie: die van de kin. 

Een stadium in de ontwikkeling van een file is een snapshot van de file. De inhoud van dit snapshot 

staat in een worm (write once read many-times) file. Traditioneel heet zo'n wormfile een “version”. 

Zo'n version kan kan worden hergebruikt. Meestal in een file in een andere drawer, die tot dezelfde 

kin behoort. Een version mag meer dan eens voorkomen in de content course van een file: 

bijvoorbeeld ten gevolge van een “undo” operatie. In de content course van de file staat een reeks 

referenties naar versions, die zelf in een pool zijn opgeslagen. In plaats van content course kunnen 

we ook spreken van een version course. 

De huidige toestand, of de toestand die een file of een folder had tussen twee events heet een 

snapshot. De course van een element kan worden gezien als een reeks snapshots, of als een reeks 

events die zijn gesorteerd op transaction time. 

Een transaction kan meerdere files en folders wijzigen. De mutaties van de transaction die slechts 

één file wijzigen noemen we een event. Eén enkele wijziging die een event teweeg brengt noemen 

we een event item, of een course item. Een event item breidt slechts één elementaire course (name, 

folder reference of version, e.d.) uit. De wijziging die een transaction teweegbrengt, de verzameling 

mutaties, noemen we een changeset. (Ik vond ook het woord “patch” voor changeset. Binnen 

Climbexion wordt het woord “patch” soms gebruikt voor changesets die gestuurd worden naar 

andere teams). 

Transactions mogen niet tegelijkertijd door elkaar heen worden aangebracht: er is een course van 

changesets. Het effect van een changeset is een nieuw snapshot in de drawer en wordt wel een 

Pagina: 56 / 230 

Snapshots



2.2 Begrippen 

“revision” genoemd. 

De event items die een file wijzigen worden toegevoegd aan een course van de file, die daardoor in 

een nieuwe toestand komt. Nieuwe toestanden van folders worden veroorzaakt door wijziging van 

hun name of één van hun andere eigenschappen, en toegevoegd aan hun eigen courses. 

Transactions, events, event items, kins, files, en versions kunnen attributes bezitten die geen 

succession zijn: Bijvoorbeeld de mededeling: deze transaction lost probleem X op, of Deze version 

is gekopieerd uit Project Y. Ze vervangen geen oude werkelijkheid door een nieuwe. Soms is er 

geen garantie dat de informatie correct is. Dan geldt niet “valid time”=”transaction time”. Er is geen 

course of development, maar hoogstens een course of metadata corrections, die hopelijk eindigt 

zodra de informatie correct is. De timestamps in een course of metadata corrections zijn transaction 

times, maar geen valid times: ze “erven” de valid time van het object waarop ze slaan. 

Voor een folder geldt wat voor een file geldt: er is een kin die hij vertegenwoordigt. Een folder is – 

net als een file – een element. Voor een element in zijn algemeenheid geldt: er is een kin van het 

element. 

Op een zeker tijdstip geldt: In een folder staan files en folders. Dit is de “memberset” van de folder. 

De “inner-reach” van een folder is een verzameling elements. Ze bestaat uit de folder zelf, zijn 

memberset, en de inner-reach van de folders die tot zijn memberset behoren. “Shallow” en “deep” 

zijn de termen die ik elders vond. 

Veel queries in het revision control system selecteren de inner-reach van van een folder op een 

zeker tijdstip. In feite wordt nu van ieder element een snapshot geselecteerd uit zijn course. We 

zullen meestal het begrip snapshot gebruiken als snapshot van de inner-reach van een drawer of een 

folder. De begrippen event en event item zullen we echter specifiek gebruiken voor een toevoeging 

aan een specifieke course. Een snapshot is een willekeurig tijdstip, maar vanwege het feit dat 

transactions atomair zijn, en hun changeset helemaal wel of helemaal niet is geïmplementeerd, 

kunnen we slechts snapshots gebruiken die een changeset volledig insluiten of uitsluiten. Snapshot 

timestamps zullen eventueel worden afgerond zodat de toestand die ze duiden jonger is dan de 

changeset die ingelijfd werd op die tijd, maar ouder dan de volgende changeset. 

Het lijkt erop dat we een aantal (bijna) synoniemen hebben geïntroduceerd: transaction, changeset, 

revision, snapshot, waarmee we zienswijzen of effecten van hetzelfde fenomeen aanduiden. 

Sommige folders worden package of subsystem genoemd. Als ik het heb over een package dan 

bedoel ik de inner-reach van de folder. Een package representeert een eenheid software die 

uitgewisseld wordt. Een package wordt in zijn geheel beheerd. Er is een eigenaar. Voor packages 

gelden de volgende opmerkingen: 

● Een drawer bestaat uit packages. De packages vormen een tree. We introduceren een nieuw 

element: de “package reference”. Een reference staat in het ene package en wijst naar een 

ander. Zo wordt de tree gevormd: een verwijzing wijst van de top af. Een package reference 

heeft courses: name, folder reference, existence. 

● Het begrip inner-reach moet nu aangepast worden. Een package reference naar een ander 

package behoort tot de inner-reach, maar het andere package zelf niet. Naast deze nieuwe 

definitie van inner-reach voor folders en packages bestaat er soms behoefte om alles 

binnen een drawer aan te duiden: dan noem ik expliciet: de inner-reach van een drawer. 

● Een top folder van een package blijft altijd de top folder van het package: er is geen course 

van folder references. Ook is er geen course van names. De eigenschap top of package van 

Pagina: 57 / 230



2.2 Begrippen 

een folder is er bij het ontstaan van die folder, de eigenschap kan niet later ontstaan, en de 

folder kan deze eigenschap niet verliezen. 

● Wat ik een drawer noem wordt dikwijls een “tree” genoemd. Bedoelt wordt een folder en 

file tree. Men moet dan denken aan een groeiende boom die uit de gezamenlijke courses van 

alle elements bestaat, zoals een file een groeiende file is. In dit verhaal gebruik ik het woord 

tree alleen bij een snapshot, waarschijnlijk vind ik het een moeilijk begrip: bij een groeiende 

Pagina: 58 / 230 

Inner-reach en Memberset



2.2 Begrippen 

boom zie ik niet iets voor mij waarvan bijvoorbeeld een tak zich verplaatst naar een andere 

tak. 

● Voor een folder tree van een drawer geldt dat de name van een package reference de name 

wordt van de top folder van het gerefereerde package. 

● Een drawer zelf bevat een verzameling (Engels: set) packages. Ieder package bevat een 

verzameling elements. Er is op ieder moment één top package. De reference ernaar staat in 

de drawer. Verder is er op ieder moment per package hoogstens één reference geldig naar dat 

package. Die reference moet ook nog eens in een ander package of in de drawer staan. Als 

een package voorkomt in een drawer dan is het wel de bedoeling dat er minstens een tijdje 

een reference naar het package geldig is. De courses van een package reference in een 

package: er is een existence course, en er is een name course, en een folder reference course, 

maar geen course van references naar packages. Het element heeft gedurende zijn leven één 

reference naar de kin van één package. De package reference naar het top package van de 

drawer kent mogelijk wel een course van package references, maar het besluit daarover 

moet nog genomen worden. 

● Een element in een package kan het package niet verlaten. Folder references zijn lokaal 

binnen het package. De kin van een element wordt geregistreerd en bijgehouden bij het 

package in een kin pool, ook de versions van een file komen in een package pool. 

● Omdat een package een eenheid van beheer is zouden changesets bijgehouden kunnen 

worden per package. Ieder package heeft dan één changeset element. De uiteindelijke 

beslissing hierover stel ik uit naar de formele beschrijving van het systeem. 

Er zijn waarschijnlijk drawers die slechts één package bevatten. De later te benoemen importdrawers 

en export-drawers komen in aanmerking om één package te bevatten De drawer kan dan 

vereenzelvigd worden met het package, er is geen onderscheid. Al met al lijkt het er momenteel op 

dat een drawer een andere “bolster” heeft dan een package, omdat de laatste altijd in een drawer zit, 

terwijl een drawer in een file system zit, misschien als folder, misschien als file. 

Pagina: 59 / 230 

Samenvoegen package reference en top folder in een working-tree 

Package en top-folder kunnen eventueel gereduceerd worden tot één enkel element.



2.2 Begrippen 

Er is eventueel een alternatief voor het top-package. Een drawer zou standaard een top-folder 

kunnen bevatten, net als een package. Het werken met packages is dan een optie. Een besluit 

hierover stel ik uit. In de formele definitie moet maar een keus worden gemaakt. Voorlopig is een 

drawer een verzameling packages 

Het meest recente snapshot van een drawer (het heden, “nu”) heet de tip van de drawer. De tip kan 

worden gekopieerd naar een overeenkomstige folder structuur op een desktop, laptop of een server. 

Zo'n kopie heet een working-tree (ik vond ook de termen working folder, working directory en 

sandbox). In een working-tree wordt een package reference en de bijbehorende top-folder van het 

package samengevoegd tot één folder. 

In zo'n working-tree kunnen updates plaatsvinden. De gewijzigde versions en andere course-items 

kunnen daarna met de opdracht “commit” (ook wel “check-in” genaamd) worden toegevoegd aan 

de tips van de files in de drawer Ze vormen de nieuwe tips van de elements. Sommige wijzigingen 

kunnen niet zonder meer aangebracht worden in de working-tree en daarna met “commit” de 

courses uitbreiden, bijvoorbeeld naamswijzigingen, folder wijzigingen, het starten of beëindigen 

van een course. Dergelijke wijzigingen moeten worden aangebracht met Climbexion software in de 

working-tree, zodat ze daarna of gelijktijdig met commit in de drawer geplaatst kunnen worden. 

Normaal gebruik ik de Engelse termen, maar ik denk dat ik het werkwoord “to commit” niet ga 

vervoegen in het Nederlands. Ik zal dan de term “vastleggen” gebruiken: “iets met commit 

vastleggen” 

Een file in de working-tree wordt beschouwd als een kopie van de tip van een element als zijn pathname 

overeenstemt met die van het element, en als zijn timestamp (last changed date/time) 

overeenkomt met de timestamp van de tip van het element. Als de timestamp afwijkt dan wordt 

verondersteld dat de file een andere version is geworden. N.B. De timestamp in een filesysteem is 

vaak minder precies dan die in de repository. Maar voorlopig moet Climbexion het er maar mee 

doen. 

Om een nieuwe file in een drawer te specificeren wordt een “add” opdracht gebruikt. In één add 

opdracht kunnen meerdere elements worden toegevoegd aan de drawer. Meestal door in de 

working-tree vast te stellen wat erin voorkomt dat niet inde drawer staat, maar wel van belang is. In 

Climbexion zou “add” gebruikt kunnen worden om een nieuwe kin te duiden, terwijl “copy” of 

“inherit” gebruikt wordt als de kin reeds elders bestaat. Bij het gebruik van inherit wordt niet 

gekeken in de working-tree, maar in een andere drawer. Bij add en inherit worden name en folder 

reference initieel ingevuld, die courses zijn er daarna reeds. Merk op dat een nieuw package niet 

zonder meer kan worden afgeleid uit een nieuw element in een working-tree. Verder wordt de term 

“check-out” gebruikt om de working-tree af te leiden (soms opnieuw) van de tip van de drawer. 

Voor het beëindigen van (de courses van) een element zou “remove” of “delete” kunnen worden 

gebruikt. Het gebruik van “add” wijkt af van het gebruik in sommige andere systemen. Daar werkt 

men met een schaduw working tree, van waaruit eventueel half gewijzigde files kunnen worden 

terug gehaald in de working tree, of heel gewijzigde files met commit worden overgedragen in de 

drawer. Wij gaan uit van persoonlijke drawers, waarin naar hartenlust wijzigingen kunnen worden 

opgeslagen en eventueel teruggehaald in de working tree, voordat een snapshot ontstaat dat kan 

worden overgedragen naar een team drawer. 

Pagina: 60 / 230



2.2 Begrippen 

Over de naamgeving 

folder: oorspronkelijk een gevouwen map om documenten in te bewaren 

file: oorspronkelijk een geordende verzameling documenten, die aan een koord zijn bevestigd. Toen 

ik kennismaakte met computer files, bestond zo'n file uit records, bijvoorbeeld klant records die de 

de rubrieken naam, adres, woonplaats bevatten. 

record: oorspronkelijk een document waarin een gebeurtenis is opgetekend. 

Het Nederlandse “kaartenbak” laat zich vertalen als “file”, maar het Nederlandse “ordner” wordt 

vertaald als “folder”. 

In een software archief denk je bij file toch meer aan één enkel document – bijvoorbeeld een source 

document – dan aan een geordende reeks documenten. De begrippen file en document zal ik door 

elkaar gebruiken, als synoniemen. Bijvoorbeeld een reeks baseline reports vormt niet een file, maar 

een file-string. 

package: pakket. Hierbij heeft men het versturen en ontvangen van de spullen op het oog. Ik 

gebruik het woord package in plaats van (sub) system omdat dit iets meer in lijn is met folder, file, 

en document. Ik denk dat mijn package voldoet aan de UML definitie. 

Drawer. filing cabinet: archief kast voor het opbergen van files en folders en packages. Helaas 

bestaat dit begrip reeds voor archief files van Microsoft. Ik denk dat ik daarom het woord drawer 

(lade) ga gebruiken. Bovendien komt dat nog het dichts bij het begrip “branch” in andere VCS 

systemen. Oorspronkelijk gebruikte ik het woord area, maar dat sloeg nergens op. Drawer als deel 

van het opbergsysteem van folders files (documenten) en packages blijft horen bij de metafoor. 

Pool wordt gebruikt in de betekenis: "common reservoir of resources". Dat is een repository 

natuurlijk ook, maar ik gebruik het begrip voor een verzameling kins, of een verzameling versions, 

of verzamelingen van andere objecten die gedeeld worden door drawers. 

Kin: verwantschap. Oorspronkelijk gebruikt ik archetype, toen stolon en ik ben blijven hangen op 

kin. Zowel het Engelse als het Nederlandse “kind” zijn hiermee verwant. Hier vond ik geen begrip 

dat binnen de metafoor bestaat. 

Pagina: 61 / 230 

Gebruikte symbolen



2.2 Begrippen 

2.2.2 De organisatie van het geheel aan drawers 

Drawers zijn er in soorten en maten. Er is een drawer voor een team dat betrokken is bij een project. 

Van zo'n drawer en de files en folders die erbij horen, wordt de volledige course bijgehouden. Zo'n 

Pagina: 62 / 230 

Drawers van een subproject



2.2 Begrippen 

drawer moet zelf ook eeuwig blijven bestaan. Een team is meestal betrokken bij meer dan één 

project. Er is dan voor elk project een team-drawer. 

Dan zijn er drawers voor team members. De team members wijzigingen files (via de working-tree) 

in hun eigen drawer en dragen daarna de wijzigingen over aan de team-drawer. De overdrachten 

zelf zijn te volgen in het team-drawer. Drawers voor team members moeten kunnen komen en gaan, 

ze zijn er vooral voor de actuele behoeften. Zo'n drawer is een satellite van de team-drawer. De 

team-drawer is de center-drawer van zijn satellites. De hele constellation heet naar zijn centerdrawer. 

Dit komt denk ik overeen met het “cone” model van een lifeline van Ben-Michael Schueler. Met dit 

model van recente ontwikkeling wordt het team member een faciliteit geboden om zijn eigen werk 

te reconstrueren, totdat hij de taak die tot het werk heeft geleid als beëindigd beschouwt. 

Een overdracht van member naar team brengt de team-drawer "in sync" met (een deel van) de 

satellite van een team member. Maar er is ook een faciliteit waarmee het team member zijn satellite 

"in sync" brengt met die van het team. 

Een satellite is typisch een werkplaats, waar transactions (changesets) op de center-drawer worden 

voorbereid. De transactions in een satellite zijn daarom meestal nogal fragmentarisch van aard. Bij 

de overdracht naar de center-drawer wordt een course traject uit de satellite dan samengevat tot één 

event item. Ook kan een transaction in de satelliet een enkele version van een enkel element 

bevatten, terwijl de overdracht naar de team drawer meerdere elements en courses wijzigt, omdat 

de team area op elk moment aan allerlei eisen moet voldoen. In de courses van de satellite kun je de 

wording van een oplossing volgen. In een satellite kun je desnoods versions vastleggen: “gewoon, 

omdat het lunchtijd is”. 

Waarmee moet je een satellite vergelijken in een DAG (Directed Acyclic Graph) systeem? In de 

moderne open source version control systems, creëer je op je PC een clone van een centrale 

repository. Als je een wijziging aanbrengt dan creëer je op de tip van de clone een branch, waarin je 

de wijziging bereidt. De tip van de branch draag je daarna over aan de (centrale) repository. Een 

satellite zoals ik hem schetste is in feite een sequence van deze branches. Sterk punt van de DAG is 

voorlopig: je kunt aan meerdere wijzigingen tegelijk werken. In een satellite moet je strikt 

sequentieel werken, en voor parallellisme heb je er meer dan één nodig. Aan de andere kant, met 

satellites heb je lokaal geen clone nodig van de team-drawer. Het lijkt erop dar er twee opties zijn: 

● Je kunt werken met één satellite per teamlid, per center-drawer, per wijziging. Op je PC zou 

je dan een directory kunnen maken die correspondeert met de center-drawer, en daarin 

satellites creëren die corresponderen met een probleem (of een stukje delta processing, of 

echte nieuwbouw, of een change request). 

● Als je je satellite niet meer nodig hebt kun je die naderhand met “append” toevoegen aan 

de “history” satellite. 

Als je een branch creëert wordt er een working-tree gecreëerd, met folders en versions, en als je een 

satellite creëert wordt bovendien het eerste snapshot gecreëerd in de satellite. De aanmaak tijd van 

een satellite is daarom slechter dan de aanmaak tijd van een branch, gesteld dat de betreffende 

revision control software door dezelfde persoon ongeveer gelijktijdig is gemaakt. Dit is voor mijn 

hobby acceptabel genoeg. Bovendien, ik wil toch zien of het mogelijk is om met een strikt lineaire 

en onvertakte structuren te werken. 

Vaak vindt de overdracht van satellite naar center-drawer niet rechtstreeks plaats, maar via een 

transfer-drawer. Er vindt (periodiek, bijvoorbeeld 's nachts) een validatie plaats van de 

Pagina: 63 / 230



2.2 Begrippen 

overgedragen software, en na acceptatie wordt de center-drawer bijgewerkt, vanuit de transfer 

drawer. In wezen kan de inhoud, als een envelope niet wordt geaccepteerd wel deel uitmaken van de 

transfer drawer, maar niet van de team drawer. 

In Synergy gebruikten we een soort “transfered” status in plaats van een transfer drawer. Zo'n 

status kun je beschouwen als een tijdelijke branch aan de tip. Bij een status verandering van alle 

items in de branch naar “accepted” veranderde de branch in een uitbreiding van de trunk. Dit was, 

meen ik, zo gemaakt dat items afzonderlijk van status konden veranderen. 

Binnen de drawer van een team zijn er packages die onderhouden worden door het betreffende 

team, en packages waarop het team zich abonneert. Een ander team in hetzelfde master project 

onderhoudt andere packages. Er is dan ook een uitwisseling van recent gewijzigde packages. 

Tussen projects die hetzelfde package onderhouden (“sister-projects”) wordt er onderling ook heel 

wat uitgewisseld. Een team in een nieuw project baseert zijn packages op die van voorgaande 

projects. In sommige fasen wordt een package volledig gesynchroniseerd met die uit een ander 

project, op een ander moment moeten slechts oplossingen van bepaalde problemen worden 

overgenomen. Voor beide methoden moeten er faciliteiten komen. 

We hebben te maken met geheimen. Klanten willen bijna nooit dat hun oplossingen en methoden 

door NXP worden doorgegeven aan andere klanten. Er moeten daarom een behoorlijke barrières 

zijn tussen projects voor verschillende klanten. Vaak wordt geëist dat NXP voor een klant een eigen 

repository gebruikt. 

Er kunnen export limitations gelden bij de overname van wijzigingen tussen de sister-projects. In 

een package dat je aanpast volgens specificaties van klant A kunnen geheimen zitten die klant B niet 

mag weten. Je kunt dan niet onbeperkt alles overnemen als je hetzelfde package aanpast voor klant 

B. 

Ook NXP heeft geheimen, die hopelijk een (mogelijk tijdelijke) voorsprong geven op concurrenten. 

NXP wil niet dat die geheimen via een klant of zo in het bezit komen van de competitie, want ze wil 

zo lang mogelijk profiteren van de voorsprong, immers alleen met een voorsprong verkoopt ze veel 

chips voor een behoorlijke prijs. Zolang de digitale tv sterk in ontwikkeling is kan er geconcurreerd 

worden met geavanceerde oplossingen, en dat gebeurt dan ook. Enerzijds gebeurt dit met patenten, 

en anderzijds met verrassingen (geheimen). 

Niet alleen zijn er de barrières tussen de sister-projects, maar ze zijn er ook tussen teams in 

hetzelfde master project. Soms stellen teams slechts de binaire executable componenten en de 

interfaces van een package beschikbaar: er moeten faciliteiten komen om export limitations te 

realiseren. 

Een team dat zich abonneert op packages is vaak niet geïnteresseerd in alle files in alle folders. 

Source files zijn belangrijk voor debugging, maar documentatie niet direct. Alles wat te maken heeft 

met het specifiek testen van het package is niet van belang in de drawer van een ander team. Er 

moeten dus faciliteiten komen om query's met import limitations mogelijk te maken. Dit is vooral 

een optimalisatie. Binnen een team kan de ene persoon zich bezighouden met een test van het hele 

product, de ander is meer geïnteresseerd in de test van een layer, en heeft dan minder packages 

nodig. Hier moeten zorgvuldig gekozen selecties zorgen voor een beperkte samenstelling van een 

Pagina: 64 / 230



2.2 Begrippen 

satellite, ook hier is sprake van limited import queries. Een working-tree van de totale software 

stack is inmiddels tientallen gigabytes groot. Met alle consequenties voor importeren, exporteren, 

synchroniseren, en compileren: allemaal processen die veel tijd vergen, en zelfs in belangrijke mate 

de doorlooptijd en capaciteit van een project bepalen. Import limitations kunnen een query betreffen 

van de files die je wilt overnemen uit een andere drawer, gewoon omdat je daarbuiten niets wilt 

overnemen uit die drawer. Maar ook kan het zijn dat je bepaalde files of folders nooit in je drawer 

wilt hebben, dan “hangen” de import limitations niet aan de query, maar aan de drawer. 

Mogelijk leidt het bestaan van de limitations tot subpackages. Om import limitations te faciliteren 

zou mogelijk een subpackage gedefinieerd kunnen worden ten behoeve van de unit tests. Om 

geheimen te isoleren zou men ook een subpackage kunnen gebruiken. Voorlopig ga ik ervan uit dat 

een subpackage mogelijk is door hem als een gewoon package te definiëren, indien daar behoefte 

aan is. 

Niet alle drawers van een team zullen dezelfde import limitations krijgen. Tijdens het ontwikkelen 

gebruikt een programmeur vaak documentatie van interfaces en componenten. Voor het analyseren 

van problemen bijvoorbeeld zal je soms willen beschikken over de documentatie van de packages 

waarop je bent geabonneerd. Deze zijn dan bijvoorbeeld te vinden in de import-drawer, of de teamdrawer. 

Maar in een satellite voor een team member moet het voldoende zijn om te kunnen 

compileren en linken, en om de eigen documentatie te wijzigen. Ondanks import limitations kun je 

toch vaak beschikken over de documenten die je weert: ze staan immers in de drawer waaruit je 

importeert. 

Een import-drawer is een drawer waarin de packages van andere teams uit hetzelfde master project 

worden binnen gehaald. Een team heeft één zo'n import-drawer voor ieder van zijn projects Hierin 

zijn alle baselines, dus ook de nieuwste baselines van de packages beschikbaar, ook als ze (nog) niet 

zijn ingelijfd in de team-drawer. Misschien zijn er meerdere import drawers en bevat zo'n drawer 

slechts één package. Een externe referentie zoals een referentie naar een ander package, hoeft in 

zo'n drawer niet te worden opgelost. 

Een export-drawer is een drawer waarin de baselines van de eigen packages worden geplaatst. Om 

een eigen package te gebruiken in een ander project binnen het team gelden meestal geen 

beperkingen, en soms door de klant gevraagde restricties. Om zo'n package beschikbaar te stellen 

aan een client of een supplier gelden vaak wel export limitations, die van NXP. Vanuit deze drawers 

kan een package geëxporteerd worden naar een ander team of een ander project of beide. De export 

limitations die moeten worden gerealiseerd zijn afhankelijk van de rechten van het ontvangende 

team. Mogelijk bevat een export drawer ook precies één package. 

Een Project is een begrip dat ook binnen een revision control system gebruikt wordt Een team dat 

deelneemt aan een (master) project van een client, zorgt voor een (sub) project. Binnen dit 

subproject worden de drawers gecreëerd. Een team dat deelneemt aan tien projects heeft dus tien 

team-drawers. Een ander team, dat deelneemt aan vijf projects heeft vijf team drawers, en natuurlijk 

ook vijf import drawers enzovoort. Als twee teams deelnemen aan één (master) project dan heeft 

ieder team daarin zijn eigen subproject met zijn eigen drawers. De subprojects van een team worden 

door mij sister-projects genoemd. Een enkel package wordt beheerd binnen een aantal sisterprojects. 

Sister-projects kunnen verdeeld zijn over enkele teams. 

Voor testers komt er mogelijk een aparte drawer, de test-drawer. Veel tests worden gedaan op 

baselines van packages, en niet op packages die van de ene naar de andere baseline onderweg zijn. 

Pagina: 65 / 230



2.2 Begrippen 

Eigenlijk worden baseline tests gedaan op de voorlaatste fase van een package, voordat de baseline 

definitief is. Zelf beheren de testers een aantal package -, layer -, en product - test-cases. Er is een 

bewaar structuur, waarvoor het revision control system een folder structuur biedt. Test-cases worden 

samengesteld tot tests. Momenteel worden veel test-cases gedefinieerd in excel sheets. Ik vermoed 

dat dit nodig is voor een tool van de TMap methode. Ik denk dat dit niet zonder meer een voordeel 

is, want nu kan er niet geprofiteerd worden van standaard build - en merge - en synchronisatie - 

faciliteiten, die gebaseerd zijn op folder structuren en tekst-files. Naast test-cases, en tests en hun 

documentatie, zijn er nog de test-logs en test-results, die het waard zijn om te worden bewaard. 

Verder maken testers een progress report dat bewaard moet worden. Ook testers werken 

projectmatig, en ook hun drawers zijn exclusief voor een bepaald project. Mogelijk worden hun 

elements opgenomen in de team-drawer, en worden import limitations gebruikt als hun scripts niet 

nodig zijn. 

Als een nieuw subproject start, dan worden de eigen packages gekopieerd vanuit een sister-project 

dat deel uitmaakt van een ander masterproject, en later mogelijk bijgewerkt met wijzigingen van 

een sister-project. Hiervoor gebruiken we mogelijk een speciale import-drawer: Merge-importdrawer. 

In een subproject is er een merge-import-drawer voor ieder sister-project waaruit 

groepsgewijs wijzigingen worden overgenomen. 

Bij het oplossen van problemen is de eerste stap die genomen moet worden: reproduceer de fout. 

Meestal moet de oplossing gerealiseerd worden in de meest recente versie van de team-drawer (via 

een satellite van een team member). Soms is het probleem daar niet te reproduceren, althans niet 

met de aanwijzingen in het problem report. Dan moet er geanalyseerd worden met behulp van de 

drawer van het team dat de fout ontdekte. Hiervoor wordt een expose-drawer bijgehouden. Met in 

acht neming van export limitations wordt hier een omgeving bijgehouden, die meestal via het web 

is te benaderen, en waaruit info-trees kunnen worden getrokken. De expose-drawer is van het team 

dat het probleem ontdekte. Eén van de dingen die je dan bijvoorbeeld kunt doen: 

Je probeert of je het fenomeen kunt opwekken op een andere manier die wel 

reproduceerbaar is in de meest recente versie van de team-drawer. 

Het is me wel eens overkomen, dat ik niet de fout reproduceerde, maar een fenomeen dat er wat op 

leek. Gelukkig vond niemand het erg, dat ik het verkeerde probleem had opgelost, maar 

administratief (zie 2.5) was dat toch wel wat werk. 

Een team baseert zijn packages op die van het reference project, en wisselt soms oplossingen van 

problemen uit met het reference project. Dit moet soms kunnen met verschillende generaties van 

één revision control system, en heel soms met een totaal ander revision control system. Het kan ook 

zo zijn dat een team van de klant andere revision control system software gebruikt dan de NXP 

teams. Dan moet uitwisseling van software nog steeds mogelijk zijn. 

Pagina: 66 / 230



2.2 Begrippen 

2.2.3 De organisatie van pools 

Pools zijn er voor versions, en voor kins. Iedere package heeft zijn eigen pools, waarin de versions 

en kins staan waarnaar wordt verwezen vanuit de inner-reach van drawers. Om redenen van 

optimalisatie robustness en security kunnen er locations bestaan. Op iedere location staan local 

pools die de drawers bedienen die tot de location behoren. Een local pool bevat een subset van de 

kins van een package, en een andere een subset van de versions van de kins. Bij overdrachten vanuit 

een drawer op location A naar een drawer op location B worden indien nodig kins en versions 

gekopieerd. Een URL (uniform resource locater) identificeert een location, pool of drawer, of 

kortom een resource. 

Pagina: 67 / 230 

Kin en version pools van Party F



2.2 Begrippen 

Local pools zijn er op de server van een team. Deze pools bedienen de center-drawers, de 

import-drawers, de full export-drawers en de full expose-drawers. Voor export-drawers met export 

limitations komen er pool verzamelingen per party indien nodig. Er zijn twee soorten export 

limitations: de NXP pools dienen voor distributie binnen het master projects, de CLIENT pools 

dienen voor de distributie van NXP software binnen sister projects, tenminste als het package client 

geheimen bevat. 

Voor ieder package is er een centrale location Een pool daar wordt gewijzigd zodra een kin of een 

version in twee of meer locations voorkomt, dan wordt de entiteit ook toegevoegd aan de centrale 

pool. Elk package heeft zijn eigen centrale. Als attributes van een version of een kin wijzigen dan 

worden die gepusht naar de centrale location, tenminste als daar de version of de kin voorkomt en 

vandaar met pull methoden gedistribueerd. Eventueel worden notificaties gestuurd naar 

belanghebbenden. 

Overigens: onze partners in een masterproject gebruiken onze export pools voor het overnemen van 

attribute wijzigingen. 

Eventueel is er een tree van centrale pools, waarvan de nodes een organisatorische eenheid 

bedienen. 

De centrale version pool van een package bevat geen versions, dat wil zeggen, niet de content van 

de versions, maar slechts de attributes. 

Van envelopes (zie 2.2.6) kunnen er ook lokale kopieën voorkomen. Centraal is de constellation 

pool, en lokaal zijn de PC pools van de teamleden. Ook nu worden nieuwe envelopes en 

wijzigingen gepusht vanuit een lokale naar de centrale pool, en vandaar uit met een pull methode 

gedistribueerd. Een teamlid bepaalt welke envelopes lokaal op zijn PC worden bewaard, en 

hoelang. 

2.2.4 De organisatie van snapshots 

Binnen ons team werden 's nachts de overdrachten van de teamleden getest en daarna werden de 

overgedragen wijzigingen aangebracht in de team drawer. Dan werd er een tag geregistreerd. Een 

tag definieert de toestand (inner-reach) van een drawer op een tijdstip. Zo'n geregistreerd snapshot 

garandeert een bepaalde kwaliteit van de drawer. In ons team was er de garantie dat de drawer goed 

door een acceptatie test kwam. 

De meest recente tag heet een tip-tag. 

Een package (of vaak een groepje packages) kan een stadium bereiken, waarop er een baseline 

wordt geformuleerd, en geregistreerd. Bij een baseline hoort een baseline report. Dit document 

bevat informatie zoals: de problemen die zijn opgelost en de planning items die zijn gerealiseerd, 

misschien enige baseline supplement (patch) informatie. Ook worden de baselines van andere 

packages genoemd waarmee het package is getest. Verder staat erin op welke hardware het package 

moet kunnen werken, en nog veel meer informatie. Zo'n baseline van een package wordt 

geëxporteerd naar andere teams samen met het baseline report. Tussen baselines door kunnen er 

baseline supplements (tussentijdse wijzigingen) nodig zijn op het package. In Climbexion 

definieert de baseline een snapshot van één of meer packages. 

Pagina: 68 / 230



2.2 Begrippen 

Baseline report: Eerst noemde ik het “baseline document”. Later herinnerde ik mij dat een report 

een beschrijving is van iets dat geobserveerd kan worden. Als je werkt met fasen is een report een 

afsluitend document van de oude fase. Dat geldt ook als je vooral faseert om regelmatige 

uitwisseling van software te bewerkstelligen. Andere documenten zijn dan een stuk minder 

belangrijk, zoals een risico analyse en een plan van aanpak voor de volgende fase, die hoeven 

misschien pas als een echte project fase is bereikt. Vaak is er wel een plan voor de volgende fase, 

dikwijls vind je dat in een verslag van een vergadering. 

Ik denk tags en baselines te realiseren in speciale elements. Tag-elements komen in de absolute top 

folder van de drawer, en baseline elements in de top folder van het package. Elke keer dat er een 

nieuwe tag of baseline wordt gedefinieerd wordt de course van het betreffende element uitgebreid 

met een item. Ook als een bundel packages een nieuwe baseline krijgt, dan nog is het zinvol om een 

baseline per package te specificeren, gezien de documentatie (het baseline report) die er bij hoort. 

Als een nieuwe baseline van een package geïmporteerd wordt, dan wordt als laatste een event item 

uitgevoerd waarmee de baseline tag wordt geïmporteerd. Als een satellite gesynchroniseerd wordt 

met de tip-tag van een center, dan wordt het tag-item als laatste gekopieerd. De periodieke baselines 

van een package komen in één tag-element. Maar de bijbehorende baseline reports komen in andere 

elementen. 

Bij tijd en wijle wordt een snapshot verheven tot “project milestone”. We spreken af dat dit 

snapshot altijd een baseline is. Dit heugelijke feit mag geregistreerd worden door een extra tag toe 

te voegen aan een package of een drawer. Deze milestone tag ontstaat pas als het snapshot reeds 

bestaat, en mogelijk opgevolgd is. Er geldt dus doorgaans dat transaction time en valid time 

verschillend zijn. Vaak volgt zo'n eenmalige tag op een audit, die het licht voor de volgende project 

fase op groen zet. We kunnen dit eventueel ook realiseren door een attribute toe te voegen aan een 

baseline tag, die hiermee extra wordt gemarkeerd. Mogelijk kent een subproject milestones, die 

gelden voor meerdere packages, misschien gelden milestones voor het master project, en als 

zodanig voor de subprojects en hun packages. De kunst is natuurlijk om deze markeringen niet 

alleen in de export-drawer te realiseren, maar ook door te voeren bij de afnemers. 

Tags worden in andere revision control systems wel “label” genoemd. In Software Configuration 

Management wordt het begrip “baseline” hiervoor gebruikt. Ook de term “milestone” komt voor. 

Wij zullen het woord “baseline” gebruiken voor package tags, tags voor drawer tags, en milestones 

voor fase overgangen van een project. 

Tags worden waarschijnlijk direct aangebracht in de drawer, zonder envelope. Ze zijn hun eigen 

changeset. 

Tags kunnen uit een team-drawer gekopieerd worden in een satellite. De tag-name is bijvoorbeeld 

10 augustus 2008, P.M , en het tijdstip waarop de satellite gesynchroniseerd wordt is 11 augustus 

2008, 11:30:12. Dit is dan de timestamp van het course-item waarmee de tag-name verschijnt in de 

satellite. Als de name gebruikt wordt voor een snapshot in de satellite dan wordt bij de name de 

timestamp van het event bepaald, en daarmee de timestamp van het snapshot. De name geeft terecht 

aan dat het hier een frozen moment betreft die de team-drawer op het aangegeven tijdstip had. Dit 

gaat goed als gesynchroniseerd wordt met behulp van de tag. Synchroniseer je met een willekeurige 

Pagina: 69 / 230



2.2 Begrippen 

timestamp, en wordt daarbij een tag name gekopieerd, dan geeft daarna het gebruik van de tag name 

een onbedoeld snapshot in de satellite. Als je synchroniseert op de tip van de team-drawer, dan moet 

je vooraf synchroniseren op de tip-tag, anders is de tip-tag onbruikbaar geworden. Ditzelfde geldt 

voor baseline-tags. Ook deze worden als laatste gekopieerd als het package wordt gekopieerd, 

bijvoorbeeld vanuit de export-drawer van team1 naar de import-drawer van team2. 

Een Tag element heeft een name bijvoorbeeld “fortnightly”. Deze name heeft uiteraard een course 

of development. Daarnaast heeft elk snapshot dat gedefinieerd wordt (de tag) een name 

bijvoorbeeld “baseline 2004-03-12”. 

De werkwijze van NXP zal waarschijnlijk toelaten dat tags toegevoegd worden als gewone 

elements waarvoor geldt valid time = transaction time. Omdat één persoon, de build-manager ze 

toevoegt aan drawers die alleen hij wijzigt. Dit omdat het werk van ontwikkelaars niet onmiddellijk 

wordt toegevoegd aan de courses in de team-drawer, maar eerst een validatie ondergaat, die 

uitgevoerd wordt door de build-manager, of door een script van hem dat laat in de avond wordt 

uitgevoerd. Bij meer vertrouwen in de werkwijze van de ontwikkelaars kan deze procedure 

wijzigen, en zou er een situatie kunnen ontstaan waarin tags worden toegevoegd aan reeds 

opgevolgde snapshots, die een validatie hebben doorstaan. Dan geldt bij het plaatsen van de tag dat 

transaction time en valid time kunnen verschillen. Maar als de tip van drawer 2 gesynchroniseerd 

wordt met een snapshot, dat benoemd is in een tag van drawer 1, dan wordt de tag mee gekopieerd 

en geldt valid time = transaction time. 

Transactions worden ook wel changesets genoemd. De eerste aanduiding slaat meer op de 

handeling, en de tweede op het effect of de inhoud ervan. Net als tags en baselines zijn transactions 

een speciaal element. Zo horen echter bij een drawer en je kunt ze niet kopiëren naar een andere. De 

changesets zijn de versions van het transaction element. Ze komen zeker niet in een pool maar 

horen bij de drawer, en ze zijn niet herbruikbaar. Naast nuttige informatie voor gebruikers wordt het 

element gebruikt door de repository software om een aantal acties te optimaliseren. Als 

geregistreerde snapshots is het een reeks waarin elk snapshot verschilt van zijn voorganger. Tags en 

baselines verschillen een geheel aantal changesets (0 of meer) van hun voorganger. Changesets 

laten zien wie wat wanneer gewijzigd heeft. In drawers kan er bij een changeset een verwijzing 

staan naar een “envelope” staan (zie 2.2.6), of een verwijzing naar een gebruiker, en enig 

commentaar. 

Als de wijzigingen die in een satellite zijn gemaakt worden overgenomen in de team-drawer, dan 

wordt de tip van de satellite overgenomen, of wel de changesets van de satellite worden samengevat 

tot één changeset. Als een baseline wordt geplaatst in de export-drawer dan wordt de tip van de 

team-drawer overgenomen in de export-drawer, en de changesets in de team-drawer worden 

samengevat in één changeset in de export-drawer. Ook als satellites wijzigingen overnemen uit een 

team-drawer, dan wordt de tip van de team-drawer overgenomen, met in inachtneming van import 

limitations. Ditzelfde geldt als wijzigingen worden overgenomen in de team-drawer vanuit de 

import-drawer. Kortom changesets zijn specifiek voor een drawer. 

Een folder-structuur op een desktop, laptop of server, in het lokale file system, die een kopie is van 

een snapshot (meestal een tag of een baseline) van een drawer heet een info-tree. Je kunt wel 

wijzigingen aanbrengen in een info-tree, maar die kan je met “commit” niet vastleggen in de 

drawer, dat is het enige verschil met een working-tree. Info-trees zijn bijvoorbeeld van belang bij 

het analyseren van fouten. Stel een simpele fout: je zapt van het ene naar een ander kanaal en 

daarna hoor je geen geluid. Hoe vind je nu de statements in de software die fout zijn, het is zoeken 

Pagina: 70 / 230



2.2 Begrippen 

naar een naald in een hooiberg? Nou, bijvoorbeeld als volgt: 

Met behulp van een info-tree waarin successievelijk verschillende snapshots worden 

gedownload, kun je vaststellen wanneer de fout voor het eerst optrad. Daarna bepaal je wat 

er toen in het revision control system gebeurd is, en zo vind je de fout. (dit is niet het enige 

middel voor fouten analyse, maar het is zeker een belangrijk middel). In het open source 

system “git” git-scm.com/ vond ik een faciliteit die dit automatiseert, met een algoritme dat 

het aantal te gebruiken snapshots minimaliseert. 

Je zou een snapshot kunnen zien als een virtuele info-tree. Zo'n virtuele info-tree kun je niet 

wijzigen, je kunt er alleen in kijken. In een gewone info-tree kun je eventueel logging inbouwen in 

een programma, of een build uitvoeren, die de binaries terug plaatst in de tree. In een virtuele infotree 

is dat niet mogelijk: die is read-only. 

Als je source code moet wijzigen, dan wil je liever geen fout introduceren. Het is dan nuttig om te 

weten waarom de software is zoals hij is. Vaak ontbreekt overzicht en inzicht. Maar het revision 

control system moet hier kunnen helpen. Kijk in (virtuele) info-trees van reference en backbone 

projects waar en wanneer een software constructie is ontstaan. Kennis over de context waarin de 

software constructie is ontstaan kan dan mogelijk behulpzaam zijn bij het verwerven van het 

benodigde inzicht en overzicht. 

Er zit vaak tijd tussen de ontdekking van een fout en de oplossing ervan. Er kan dan een info-tree 

gemaakt worden om de fout te reconstrueren met de software die indertijd is gebruikt. 

2.2.5 Other-focused files 

Het betreft hier een soort files waarmee, naar ik hoop, een uitbreiding van het gebruik van de 

repository mogelijk is. We gaan ermee, als alles goed is, van een source version control system naar 

een software version control system, en mogelijk is er enig zicht op een software project version 

control system, waarin alle relevante documenten van een project worden bewaard en beschikbaar 

gesteld. 

De versions van een source file, bijvoorbeeld een c module bevatten tekst. Deze tekst slaat op de 

version zelf. De inhoud beschrijft wat de module doet. Een source file is “self-focused”. Een version 

van de file in een course of development geeft de state-of-the-art van de file weer, en draagt bij aan 

de state of the art van het betreffende snapshot van de drawer. We zeggen ook wel: “valid time = 

transaction time”. 

Een rapport met test resultaten, een baseline report, een verslag van een vergadering, en zelf een 

executable die met een build procedure is gemaakt: ze gaan allemaal over iets buiten henzelf. Deze 

files zijn “other-focused”. Een consequentie is dat voor het inbrengen van versions niet hoeft te 

gelden: “transaction time = valid time”. Het zijn wezenlijk verschillende zaken. 

Een tester selecteert bijvoorbeeld 's morgens een snapshot, test de hele dag, en plaatst 's avonds de 

test resultaten in de repository. Dan is er geen garantie dat er een snapshot is waarin het geteste en 

het testresultaat bijeen staan, tenzij je daarvoor een aparte valid time gebruikt. Ik vindt het een 

goed idee om de test resultaten samen op te slaan bij het snapshot waarop ze betrekking hebben, 

maar dit zou niet tot een procedure moeten leiden waarbij de tip van een drawer geblokkeerd blijft 

totdat de tests erop klaar zijn. Dus is er een argument om other-focused files te onderkennen, en te 

Pagina: 71 / 230



2.2 Begrippen 

faciliteren. 

Self-focused file versions zijn –, behalve de eerste –, gebaseerd op een voorganger en willen 

daarvan verschillen. Other-focused files zijn gebaseerd op een werkelijkheid, en willen daarmee 

overeenstemmen (zelfs al zijn ze met copy en paste gemaakt uit een andere file). 

Een other-focused file heeft attributes die het subject specificeren waaronder een valid time 

attribute, en versions die een transaction timestamp attribute bezitten. De belangrijkste otherfocused 

files die thuishoren in een software repository slaan op een snapshot in een drawer. Mijns 

inziens bereik je de uitbreiding van een “source revision control” systeem naar een “software 

revision control system” door een oplossing te bedenken voor other-focused files, en dan met name 

voor de “snapshot-focused” files. We gaan ervan uit dat we deze files beschikbaar stellen in de 

drawer, waarin het snapshot voorkomt. Ook gaan we ervan uit dat dit snapshot altijd een tag of 

release is. 

Binnen de other-focused files zijn er waarvan het subject buiten de repository ligt. Bijvoorbeeld de 

agenda's en verslagen van vergaderingen. Het is mogelijk op het randje om die in een software 

repository op te slaan, waarschijnlijk erover, maar goed, ze kunnen meeliften op de voorzieningen 

die ik wil treffen voor de files waarvan het subject zich binnen de repository bevindt. Om ze te 

benoemen: ze zijn “externally-focused”. 

Ik denk dat er pools van other-focused files komen (één per package per owner subproject) waarin 

de files met hun transaction time courses staan. De meeste geordend in strings. In de drawers staan 

dan references naar deze files of file-strings. Waarschijnlijk is het voldoende om file-strings te 

implementeren, single-shot files zijn dan gereduceerde strings. Die references hebben een course 

van names en een course van folder references, maar niet een string van files en geen course van 

versions. 

Snapshot-focused files bevatten informatie die min of meer intrinsiek te vinden is in het snapshot. 

Een executable die gemaakt is van een snapshot is volledig intrinsiek, maar een test document bevat 

ook informatie omtrent de TV waarop getest is, de gebruikte audio/video stromen en dergelijke, dus 

ook de nodige extrinsieke informatie. 

Binnen de other-focused files herkennen we de files die een enkel incident beschrijven: er is slechts 

één valid time, maar er zijn misschien wel meerdere versions, voordat de inhoud correct of volledig 

was. Deze files zijn “single-shot” files. 

Bijvoorbeeld review samenvattingen, of audit resultaten. Executables, baseline reports, test-reports 

van daily tests of van baseline tests, verslagen van voortgangsvergaderingen. Ik ben geneigd om 

hiervoor objecten te gebruiken met een valid time course. Zo'n complete course is dan als volgt 

gesorteerd: valid time / transaction time, terwijl meestal een subcourse gewenst is: slechts de meest 

recente (transaction time) version van een valid time wordt getoond. Deze objecten zijn een 

“repetition” van files We zullen ze “file-string” noemen. Een file uit de string heeft een valid time: 

het snapshot waarop hij slaat. De versions van de file hebben een transaction time. Twee files uit 

zo'n string zijn niet verwant in de zin van kins. Dat neemt natuurlijk niet weg, dat ze erg op elkaar 

kunnen lijken. Met de hand gemaakte repetitions zullen dikwijls voor een deel met copy en paste uit 

voorgangers zijn gemaakt. 

De string van een other-focused file-string is gesorteerd op valid time als hoofd sorteer-kenmerk. 

Pagina: 72 / 230



2.2 Begrippen 

Daarom hoeft een version die met een nieuwe transaction wordt toegevoegd aan de course niet per 

se te belanden in de tip van de string. Dit in tegenstelling tot een self-focused file waarvan de course 

altijd wordt uitgebreid aan de tip, immers de transaction time van de nieuwe version is ook de valid 

time. Een nieuwe version voor een self-focused kin wordt dan ook altijd met “commit” vanuit een 

working-tree vastgelegd, terwijl een nieuwe version voor een other-focused file kan worden 

vastgelegd vanuit zowel een working-tree als een info-tree. 

Voor own-drawer-focused files in een string geldt dat ze geen valid time timestamp hebben, maar 

Pagina: 73 / 230 

Own-drawer-focused file-string 

Als een file niet voorkomt in een snapshot dan moet dat gemarkeerd worden. Als een file geldig is 

voor meerdere snapshots dan moet dat aangegeven worden in de string. 

Het model kan eventueel vereenvoudigd worden door slechts de meest recente versie op te slaan 

van een file in de string.



2.2 Begrippen 

een tag reference attribute. Per tag reference kunnen er diverse versions zijn, met een verschillende 

transaction time timestamp, waarvan de meest recente geacht wordt de meest correcte te zijn. 

Sortering op tag levert niet per se een sortering op valid time op en is dus geen time sequence, maar 

blijft een set. De uiteindelijke string wordt bepaald in de drawer, waar het tag-element een course 

heeft. De course van het tags bepaalt de definitieve course van de file-string in de drawer. 

Er zijn twee presentatie opties voor file-strings. In een working-tree of info-tree kan gelden dat alle 

repetitions getoond moeten worden in een folder die genoemd is naar de file-string, terwijl de files 

in de folder genoemd zijn naar hun valid time reference. Dit kan bijvoorbeeld gelden voor alle 

baseline reports, of alle verslagen van meetings. Maar ook kan gelden dat slechts de occurrence van 

het snapshot getoond moet worden. Dit geldt bijvoorbeeld voor build targets, of test results. Maar 

dit kan ook gelden voor baseline reports, en ook verslagen kunnen ook als single getoond worden. 

Dan wordt de name van de file-string gebruikt voor de file zelf, en wordt er geen file-string folder 

gemaakt. 

Stel in een team drawer werd een nieuwe baseline van een package geplaatst. Na een tijdje bleek dit 

zoveel problemen te geven, dat men besloot om terug te keren naar de vorige baseline. Voor de 

course van de baseline tags betekent dit bijvoorbeeld de volgorde …, Rn, Rn+1, Rn, Rn+2, ... Dit 

geldt dus ook voor de string van de baseline reports in de drawer. 

Build Targets: Ze kunnen pas gemaakt worden als het snapshot met source files klaar is, daarna 

kan de build ze zo lang duren, dat er reeds wijzigingen zijn aangebracht in de drawer. Over het 

algemeen maakt een build manager het target, en slaat het op in de team-drawer, of in de exportdrawer. 

Anderen kunnen inmiddels reeds transfers uit de satellites hebben gerealiseerd. Om die 

reden behandelen we ze als own-drawer-focused. Ze worden gemaakt in een info-tree. Een 

bijkomend voordeel is misschien dat je de builds kunt herstellen in het snapshot waarvoor ze 

bedoelt zijn. Onder andere het volgende kan mis gaan: 

● De info-tree was vervuild met wijzigingen 

● Er waren foute opties meegegeven aan het build script 

Er zijn build targets die geëxporteerd worden. Dan worden ze zowel in baselines als in baseline 

supplements geëxporteerd. De betreffende tags moeten dus ook bijgehouden worden voor zowel de 

baselines als de baseline supplements. 

Complete build resultaten, met alle derived files: Het kan nuttig zijn om deze op te slaan, om te 

vermijden dat ontwikkelaars veel clean builds moeten uitvoeren. 

Baseline reports: Ze kunnen worden voorbereid voordat er een baseline tag bestaat in de export 

drawer, want zo'n baseline is planbaar. De satellite waarin het baseline report wordt voorbereid 

moet dan het betreffende tag-element reeds bevatten. In de betreffende satellite geldt dan strikt 

genomen niet dat het report own-drawer-focused is, immers het snapshot in de satellite voldoet niet 

per se aan de specificaties van het baseline report. Een bijkomstigheid: een fout is nog te herstellen. 

De herstelde file vervangt de foute file in het baseline snapshot. 

Component descriptions en Interface descriptions: in principe is dit documentatie over een 

component, of een interface, bedoeld om implementatie perikelen te beschrijven, voor de software 

engineer die de component als server voor zijn client software gebruikt, of die de interface gebruikt. 

Als zodanig lijken deze files in aanmerking te komen als other-focused files. Maar nieuwe files zijn 

wel gebaseerd op voorgangers als je ze wijzigt, ze nemen deel aan een ontwikkelingsgang. Ook wil 

Pagina: 74 / 230



2.2 Begrippen 

je soms versions of wijzigingen overnemen uit sister projects. In de projects waarin ik werkte zijn 

de gebruikers te overzien, en een fout hoeft niet per se hersteld te worden in de baseline, of in het 

snapshot. Zelfs als de gebruikers niet zijn te overzien, kunnen wijzigingen via de normale verbeter 

procedures worden gedistribueerd. Daarom implementeren we ze als self-focused files. We 

reserveren other-focused files alleen voor die files waarvoor het bijna niet anders kan. 

Argumenten voor het onderkennen van other-focused files zijn onder meer: 

● Er moet reeds een snapshot zijn, waarop de file slaat 

● Er is sprake van een file-string. 

● Er moet correctie mogelijk zijn in hetzelfde snapshot 

Slot opmerkingen. 

● Over het algemeen is het zo dat een file-string niet per se na iedere toevoeging aan de tip-tag 

van een package opnieuw moet worden uitgebreid met een nieuwe file voor de betreffende 

valid time. Dus in snapshots die volgen blijft de oude file zichtbaar, totdat er een snapshot 

komt waarin deze vervangen is. Ook kan het voorkomen dat je het éne moment een snapshot 

bekijkt, en je ziet een oude version, en de volgende dag bekijk je het snapshot, en nu zie je 

een nieuwere version. Deze version kan tot dezelfde file behoren, en dus dezelfde valid time 

hebben als zijn voorganger. 

● Soms is er source file. Dan komt iemand op het idee om de file te genereren, en is het niet 

langer een source file, maar een derived file en dus mogelijk een file-string. Climbexion 

heeft voorlopig geen faciliteiten om een file naadloos te laten overgaan in een file-string 

(visa versa). 

● “IBM Rational ClearCase” is een revision control systeem waarin ook build resultaten 

kunnen worden opgeslagen. (in een VOB, wat staat voor Versioned Object Base). “Odin” is 

een build systeem waarmee meerdere versies en varianten van build resultaten kunnen 

worden opgeslagen naast een source revision control system. 

● De architecten van NHSW bedachten een folder structuur waarin self-focused en snapshotfocused 

files beiden voorkomen. Nu Climbexion NHSW gebruikt als uitgangspunt, is het 

logisch dat hieraan aandacht wordt besteed. 

2.2.6 Envelopes 

In Synergy kent men tasks. Een task verwijst naar een problem report, change request of planning 

item, of een andere werk opdracht. Als je zo'n problem report of ander item oplost, dan zie je dat 

toch vooral als een stukje arbeid. We zullen ze daarom work-item noemen. 

Bij een overdracht van wijzigingen vanaf een satellite naar een team-drawer, staan de wijzigingen in 

de task. De task wordt voorgedragen en als alles goed gaat overgedragen. De overdracht van een 

task is een transaction, (een atomaire wijziging). 

Ook het inlijven van een nieuwe baseline in een team-drawer is een task. 

Wijzigingen, die van het ene project doorgevoerd worden in het andere, gebeuren door een task te 

kopiëren, en mogelijk, de kopie te modificeren. 

In Climbexion zullen we spreken over een envelope in plaats van een task. Want task is een begrip 

uit het planning en tracking gebeuren. Een envelope is voor vervoer, waar een folder is voor 

opbergen op een vaste plaats. Een envelope doorloopt stadia: Preparation, Transferred, Unallocated, 

Pagina: 75 / 230



2.2 Begrippen 

Rejected, Implemented. Bij de meeste stadia hoort een drawer waarin de wijzigingen zijn 

aangebracht die in de envelope staan. De drawers waartussen de envelope pendelt behoren tot 

dezelfde constellation. 

Te overwegen valt het woord “briefcase” voor envelope. Dit woord laat zich vertalen als aktetas, 

en is mogelijk wat minder geassocieerd met mail en messages, dus met andere begrippen uit 

groupware en project management. 

Naast de wijzigingen staan in de envelope de base versions, base names, en base folder references, 

zoals aangegeven door het team member, of zoals afgeleid door de SCM software. Dus: de nieuwe 

version x van element A is bedoeld als wijziging op de base version b. De gewijzigde name, of 

folder reference of version noemen we labored. De base version is ter controle. Als een labored 

version wordt overgedragen naar de team-drawer dan moet de base version gelijk zijn aan de tip 

version van de team-drawer. 

Zodra iemand begint aan het uitvoeren van een oplossing, maakt hij een envelope aan, of hij 

ontvangt de envelope van een voortgangsmanager. De te wijzigen files en hun course-item in de 

team-drawer worden toegevoegd aan de envelope: dit is de basis van de wijzigingen. In feite wordt 

niet de timestamp van het course-item toegevoegd aan de envelope, maar name, folder reference of 

version-id, afhankelijk van de aard van de wijziging. De file in de team-drawer wordt er (virtueel) 

door gemarkeerd, en een relatie wordt gelegd met het team member. Hierdoor moet het voor ieder 

team member zichtbaar zijn dat er aan de file wordt gewerkt. Overleg kan plaats vinden als een 

ander de file reeds heeft gemarkeerd. Deze markering zorgt voor een zo vroeg mogelijk inzicht in 

problemen met parallel updates. Als een envelope wordt overgedragen, is ook dit zichtbaar voor 

iedereen, want dan komen de labored resultaten beschikbaar. Iemand die zijn envelope wil 

overdragen en ziet dat een file inmiddels is gewijzigd moet een mogelijkheid krijgen om zijn 

wijzigingen te baseren op het te verwachten, of 

mogelijk reeds gerealiseerde nieuwe courseitem. 

De markering schuift dan naar dit nieuwe 

item. 

Pagina: 76 / 230 

Envelope state diagram 

State transitions worden gerealiseerd in 

passages 

Er is een speciale satellite, de transfer-drawer. 

Deze begint de dag, als alles goed gaat, met 

dezelfde tip als de team-drawer. De inhoud van 

envelopes die worden overgedragen wordt hierin 

meteen tijdens overdracht geplaatst, waarbij 

controle plaatsvindt of elk element in de 

envelope wel de juiste basis heeft dat wil zeggen 

dat de wijziging gebaseerd moet zijn op de tip 

van de transfer-drawer, anders wordt de hele 

envelope geweigerd. 's Avonds als een acceptatie 

test goed verloopt dan worden de verzamelde 

envelopes één voor één overgedragen naar de 

team-drawer. 's Nachts wordt een nieuwe tag 

voor de team-drawer aangemaakt. Mocht er een 

fout optreden in de acceptatie test dan kan 

besloten worden om een envelope te weigeren.



2.2 Begrippen 

De transfer-drawer wordt dan opnieuw gesynchroniseerd met de team-drawer en de envelopes 

worden opnieuw aangebracht, behalve de geweigerde. Eventuele afhankelijke envelopes, met 

elements die geen geldige basis meer hebben, omdat ze gebaseerd zijn op de geweigerde envelope 

worden dan eveneens geweigerd. Nadat een envelope is overgedragen naar de team-drawer is hij 

geïmplementeerd. 

Opmerking: de acceptatie test is slechts een deel van de daily test (regressie test). Niet alle projects 

gebruiken een acceptatie test en vaak alleen in de development fase. Wel worden er altijd ter 

acceptatie bepaalde builds uitgevoerd, die zonder compilatie-fouten moeten verlopen. 

Strikt genomen is een transfer-drawer niet nodig, omdat envelopes ook uitgeschakeld kunnen 

worden in de center-drawer, door de courses uit te breiden met events waarin de wijziging 

ongedaan wordt gemaakt. Door dit in een transfer-drawer te doen, blijven echter de courses in het 

center meer toegespitst op hun gebruik bij het vinden van fouten. Dit gaat dan ten koste van project 

evaluaties, waar je ter lering en vermaak graag de onvolkomenheden bij (de voorbereiding van) 

transfers in kaart brengt, maar die zijn terug te vinden in de transfer-drawer. 

De acceptatie test is geen volledige regressie test, maar meer een soort garantie dat de software 

bruikbaar is voor tests en debugging. Het is een “unattended test”, die geen menselijke waarneming 

of handeling behoeft. TV en Image generators worden aangestuurd door het test-script en in plaats 

van beelden geluid- waarnemingen door mensen vergelijkt het script variables en notifications met 

een norm. (De term “in plaats van” die ik gebruikte is een slordigheid In een “attended test” kunnen 

ook variables en notifications worden vergeleken met een norm, maar daarnaast kunnen ook 

menselijke handelingen worden uitgevoerd, en menselijke geluid en beeld waarnemingen bijdragen 

aan het test resultaat). Behalve de binary voor de test op een platform worden ook een aantal andere 

binaries (executables) gemaakt. Als één zo'n build mislukt, dan is dat dezelfde soort situatie als 

wanneer de test mislukt, en wordt er navenant gehandeld. 

Een envelope start zijn leven in een satellite. Bij iedere transitie verhuist hij naar een andere drawer. 

Deze transities vormen een course of development. Bij iedere transitie behoort de inhoud zoals die 

tot dan toe is bijgehouden. Deze inhoud is vanaf dat moment frozen. In de state “Preparing” kan een 

inhoud worden voorbereid die frozen is na transitie. Nieuwe wijzigingen vervangen niet de frozen 

content, maar worden opgebouwd voor een nieuwe transities. Bij envelopes spreken we over 

passage in plaats van snapshot bij zo'n state overgang. Bij een passage hoort een bepaalde 

changeset, die is toegespitst op de ontvangende drawer, tenminste als er niet sprake is van een terug 

verwijzing, of een voortijdige beëindiging. In het state diagram zijn state overgangen gekleurd die 

een changeset toevoegen aan een drawer. De events die een state overgang uitlokken zijn menselijke 

beslissingen die gerealiseerd worden door Climbexion commands. Alleen de overgangen naar de 

end state zijn automatisch (en ogenblikkelijk). 

Een satellite kan op een aantal manieren gewijzigd worden. Sommige wijzigingen vereisen een 

envelope, andere niet. Sommigen wijzigen een bestaande envelope, andere niet. In principe zijn alle 

acties die gegevens uit de team-drawer in de satellite kopiëren, en alle acties die gegevens uit 

andere drawers in de satellite kopiëren wijzigingen die niet via een envelope komen: het zijn 

autonome changesets. Wel kunnen dergelijke wijzigingen de envelope wijzigen die wordt 

voorbereid voor overdracht. 

● Synchronisatie met de team-drawer realiseert het snapshot van zijn tip-tag in de satellite en 

de working-tree: er ontstaat een nieuwe basis voor wijzigingen. Een gewijzigde basis kan de 

envelope wijzigingen, de merge van een voorheen reeds gewijzigde file, en de nieuwe tip, 

Pagina: 77 / 230



2.2 Begrippen 

met de vorige base als original kan daarna de envelope wijzigen. Voor de begrippen base, 

merge, original: zie de sectie over merging: 2.4.1 

● Er wordt niet alleen gesynchroniseerd met de tip-tag. Synchronisatie met de (verwachte) tip 

wijzigt satellite en working-tree. Een gewijzigde basis kan een envelope wijzigen. Een 

daarop volgende merge ook. 

● Manueel wijzigen van names en folder references. Dit gebeurt met Climbexion software. 

Ook de dood van een element wordt zo gerealiseerd. Dit wijzigt de working-tree. Om de tip 

van de satellite te wijzigen moeten de wijzigingen daarna of gelijktijdig worden vastgelegd. 

Sommige wijzigingen worden vastgelegd in de envelope, en dus in de satellite, en sommige 

worden eerst alleen in de satellite vastgelegd, en later mogelijk in de envelope. 

● Manueel wijzigen van names en verplaatsen van elements in de working-tree met andere 

dan Climbexion tools, moet worden ontraden, maar is niet uit te sluiten. Dergelijke 

wijzigingen kunnen met gecompliceerde commits worden vastgelegd. 

● Wijzigen of nieuw creëren van een file met een editor wijzigt de working-tree, daarna kan 

de file vastgelegd worden in de drawer, en mogelijk in de envelope. 

● In de working-tree kunnen files gewijzigd worden door het resultaat van query's in 

beschikbare Climbexion drawers. Dit betekent in eerste instantie: geen wijziging in een 

envelope. Pas als de files vastgelegd worden, wordt de envelope bijgehouden. Overigens 

moet deze methode worden afgeraden, omdat zo geen herkomst relaties kunnen worden 

gedetecteerd door Climbexion. 

● Door dergelijke queries vast te leggen in envelopes is er een herkomst relatie, en een lijst 

van wijzigingen die moeten worden geïncorporeerd. 

Bij iedere passage kan een andere persoon betrokken zijn. Dit moet geregistreerd worden in 

envelope. Er kunnen 2 personen betrokken zijn bij een implementatie, een software ontwikkelaar in 

het stadium preparing brengt de envelope in het stadium transfered, en een build manager brengt de 

envelope in het stadium implemented. Deze mensen worden geregistreerd in de envelope. Een 

envelope die 20 passages meemaakt, zal mogelijk 21 namen bevatten: één per transfer, en de naam 

van degene voor wie de envelope nu preparing is. 

Om een envelope over te hevelen van de ene ontwikkelaar naar de andere, zal de ene hem in het 

stadium unallocated brengen, Nu is hij beschikbaar voor een voortgangsmanager, die hem opnieuw 

kan toewijzen. Daarna zal de envelope door de ontwikkelaar worden gebonden aan één van zijn 

satellites, en opnieuw preparing zijn. 

Het binnenhalen van een package in de import-drawer, en het plaatsen van een package in een 

export-drawer vindt plaats met een envelope die minder stadia doorloopt. Ook het initieel vullen en 

op orde brengen van een team-drawer kan plaatsvinden met envelopes die minder stadia doorlopen, 

omdat er nog geen eisen worden gesteld aan het center-drawer, zoals “compileerbaar”, of 

“doorstaat test”. Er komen waarschijnlijk speciale envelopes voor het binnenhalen van package 

baselines in de import-drawer, of het kopiëren van een package baseline in een export-drawer. Die 

zijn waarschijnlijk simpeler dan een envelope met volledige stadia voor de team-drawer. 

Eén enkele envelope kan slecht wijzigingen bevatten voor één package. Voor complexe wijzigingen 

vanuit één satellite kunnen soms een aantal bij elkaar horende envelopes nodig zijn: er is er 

minstens één per package. De envelopes uit zo'n groep worden comrades genoemd. Er wordt een 

comrade volgorde vastgelegd zodat eventueel een labored version in de ene envelope kan dienen als 

base in een volgende. 

Pagina: 78 / 230



2.2 Begrippen 

Naast comrades die samen en tegelijkertijd, als één transaction worden overgedragen, kan het nog 

voorkomen dat een work-item niet meteen goed is opgelost met één envelope. Later start dan een 

andere envelope, waarmee het probleem hopelijk wel goed wordt opgelost. Deze envelopes vormen 

een succession. Tenslotte kan er een relatie bestaan tussen envelopes als de één de wijziging van de 

ander overneemt, zodat de wijziging gerealiseerd wordt in binnen twee constellations. De ene is de 

model envelope, en de andere de adopt envelope. 

Een voorbeeld van een envelope is te vinden in sectie 3.3.1 

2.2.7 Baseline supplements, external envelopes 

In Climbexion zijn “baseline supplements” het smeermiddel waardoor de teams onderling min of 

meer onafhankelijk kunnen bewegen. Er zijn een aantal scenario's waarin deze patches nuttig zijn: 

● Nadat een baseline is uitgegeven wordt een fout ontdekt die de voortgang van testers of 

ontwikkelaars ernstig belemmerd, of mijlpaal audits laat stranden, of een certificaat 

aanvraag of deelname aan een beurs frustreert. 

● Een wijziging vraagt een aanpassing in de packages van 2 teams. Het ene team gebruikt een 

tijdelijke wijziging in een package van de ander (en het ander mogelijk een tijdelijke 

wijziging in een package van het éne). 

● Een team gebruikt een bepaalde (ongebruikelijke) combinatie van baselines van packages 

die een incompatibiliteit opleveren, het smeermiddel maakt dat ze er nog even mee door 

kunnen gaan. Soms wil/moet een team zich concentreren op de eigen software ontwikkeling, 

en wil zich dan niet bezighouden met het invoeren van de baselines van van andere teams. 

Dan kan er een probleem ontstaan dat opgelost wordt met baseline supplements. 

Vaak zijn baseline supplements een middel om voort te gaan als plannen mislukken. 

Baseline supplements zijn –, het woord zegt het al –, een aanvulling op baselines. 

Soms is een baseline supplement onafhankelijk, soms is een combinatie van supplements nodig. 

Bijvoorbeeld als meerdere packages in combinatie moeten worden gewijzigd, of als supplement 

over supplement voorkomt. 

Bij baseline supplements geldt: De changeset komt te staan in een external envelope voor een 

wijziging die wordt aangebracht door een team op een package waarop het is geabonneerd. Vaak 

wordt de changeset ontwikkeld door het team dat er behoefte aan heeft, maar het team dat 

verantwoordelijk is voor het package is eindverantwoordelijk en geeft de external envelope uit. Een 

baseline supplement bevat een “external” envelope omdat een internal envelope circuleert binnen 

een specifiek met name genoemde constellation. Waarom een envelope en niet simpel weg een 

changeset? Wel dit is met het oog op wijziging over wijziging, en wijzigingen die in meerdere 

baselines moeten worden gerealiseerd, er is vaak een mogelijkheid om dit te realiseren met 

meerdere base/labored paren in de external envelope. 

Bij een baseline supplements hoort een “sheet” met de volgende inhoud: 

● Identificatie van het supplement. 

● Het subproject en de identificatie van degene die hem uitgeeft. 

● Package en baseline(s) waarop het supplement kan worden toegepast. 

● Het probleem dat met het supplement wordt opgelost. 

● Baselines van andere packages dan die waarin het supplement functioneert. 

● Andere supplements die ook moeten worden geïmplementeerd. 

Pagina: 79 / 230



2.2 Begrippen 

● De baseline waarin het supplement niet meer nodig is. 

● De overeenkomstige supplements voor andere baseline combinaties van eigen en andere 

packages. 

De external envelope die bij een supplement hoort wordt gemaakt in een satellite van een drawer 

waarin alle baselines van het betreffende package worden bewaard: de baseline-drawer. Er vindt 

misschien een overdracht plaats naar de center-drawer, maar zeker naar het patch registratie system, 

en vandaar naar de team-drawers van de teams die er behoefte aan hebben. Waarschijnlijk komt de 

sheet in het patch registratie systeem van het master project, maar komen de bijbehorende 

envelopes in hun export pools, om van daar uit verstuurd te worden naar ieder die er om vraagt. 

Ook de baselines van packages zouden mogelijk in dit systeem geregistreerd moeten staan, met een 

verwijzing naar de export drawers, en misschien met een uittreksel (een sheet) van het baseline 

report. Het wordt dan een baseline en patch registratie systeem. 

In de satellite vindt eerst een query plaats waarmee een baseline combinatie van packages wordt 

gerealiseerd als basis waarop de wijziging moet plaatsvinden, eigen packages komt waarschijnlijk 

uit de baseline-drawer, de overigen mogelijk uit import-drawers. 

De gewijzigde files zelf en de external envelope kunnen worden aangeleverd aan de integrator door 

een team waarin ze zijn uitgeprobeerd, of ze worden gemaakt door of namens de integrator van het 

team dat de envelope uitgeeft. 

Als een ander team de external envelope voorbereidt dan is er een mogelijk een half security 

probleem: normaal wijzig je als team alleen je eigen packages. Nu wordt van een team verlangd dat 

het wijzigt in het package van een ander. De nieuwe versions komen nu niet via importeren bij de 

package owner vandaan, maar verschijnen via “commit” in de version pool van degene die de 

external envelope maakt. De owner van het betreffende package heeft in principe geen autorisatie 

over een pool die in beheer is bij een ander team, dus er is geen harde protectie tegen lokale 

wijzigingen, hoogstens kan een team zelf een protectie instellen om zichzelf te behoeden voor 

ondoordacht wijzigingen in andermans package. Het is dan deze security die tijdelijk moet worden 

uitgeschakeld. 

Pagina: 80 / 230 

Een baseline supplements scenario



2.2 Begrippen 

Er wordt een baseline supplement gemaakt zonder export limitations. Daar worden supplements 

vanaf geleid, met export limitations die behoren bij de toegangsrechten van de subprojects. 

Het systeem dat baseline supplements toegankelijk en onderhoudbaar maakt, het patch registratie 

systeem, is een klein onderdeel van het software configuration management systeem, maar geen 

onderdeel van Climbexion. 

In sommige stadia worden wijzigingen niet per baseline maar per changeset doorgegeven naar 

andere teams 

● In het allerlaatste project stadium, als de projectleider van het master project volledige 

beheersing wil over de laatste wijzigingen, dan kan hij eisen dat alle wijzigingen 

doorgegeven worden als basic changesets, in plaats van baselines. 

● Tijdens een “field test” gaat een groepje engineers een (wereld) reis maken om op “locatie” 

de TV te testen. De problemen die ze vinden worden door de thuisbasis zo snel mogelijk 

opgelost, en de oplossingen worden zo snel mogelijk doorgegeven aan de field testers. De 

teams van de thuisbasis wisselen hier wijzigingen uit door middel van basic changesets. 

In deze gevallen is er sprake van een gewone external envelope, die met een sterk vereenvoudigd 

sheet wordt aangeleverd aan het patch systeem. 

In zo'n laatste stadium is sprake van zuiver distributed SCM. Maar toch blijven de teams daarnaast 

nog baselines uitgeven, compleet met baseline tests en baseline reports. Dit gebeurt om zicht te 

houden op het bereikte stadium, en om de kwaliteit van de software te waarborgen. Daarom wordt 

de baseline als test en verificatie discipline gehandhaafd. 

2.2.8 Resources 

In zijn algemeenheid geldt dat resources identificeerbaar zijn met een URL 

1. Kin Pools 

Lichtzinnig heb ik ervoor gekozen om entity types, en misschien toegestane names en folder 

references op te nemen bij kins. Hierdoor zijn het objecten geworden die moeten worden 

opgeslagen. Indien we ervan afzien zouden het codes zijn die bij het kopiëren mee gekopieerd 

worden. Opgeslagen kins: één centrale database per package. Eigenaar van een package database is 

de party van het subproject. Om security redenen, ten behoeve van beschikbaarheid en 

performance, en om garbage collection te vermijden zou men kunnen werken met local pools voor 

bepaalde locaties. Naast een centrale pool kunnen er local pools worden gebruikt op Pc's en bij third 

parties. Local pools op Pc's bedienen de satellites en mogelijk de clones op de PC, Uittreksels bij 

andere subprojects bedienen daar de import-drawers, en development drawers. Er is dan een 

gedistribueerde discipline wenselijk, met name om gewijzigde attributes aan elkaar door te geven . 

2. Version pools 

Hiervoor geldt in principe hetzelfde: een centrale opslag capaciteit per package. Deze opslag wordt 

niet toegankelijk gemaakt door een database server maar door een file server. Echter de 

toegangsrechten worden bepaald door de rechten in de drawers en packages waarin de versions 

worden gebruikt. In principe zijn er twee soorten recht: het recht om een version te lezen, en het 

recht om een version toe te voegen. Om security redenen, ten behoeve van beschikbaarheid en 

performance, en om garbage collection te vermijden op de centrale pool zou men kunnen werken 

met local pools. Hiervoor geldt hetzelfde als voor kins. Mogelijk is er een gecombineerde pool voor 

Pagina: 81 / 230



2.2 Begrippen 

versions en kins. Het werken met local pools betekent wel, dat er bij overdrachten en 

synchronisaties niet alleen versies gekopieerd worden van of naar working-trees, maar dat er ook 

gekopieerd wordt tussen pools. Indien men strikt met local pools werkt, zou de centrale pool geen 

content hoeven te bevatten, maar uitsluitend attributes. Deze centrale pool speelt dan een rol bij het 

doorvoeren van attribute wijzigingen. 

Een probleem met local pools wordt veroorzaakt door de attributes. Dit geldt voor versions en voor 

kins. Normaal worden pools bijgewerkt door synchronisaties van drawers of packages, of door 

transfers, of omdat satellites worden bijgehouden vanuit working-trees (commit). Hierbij zijn een 

tweetal drawers betrokken, of een drawer en een working-tree. Wordt echter een attribute 

bijgewerkt in een (local) pool, dat moeten de attributes worden bijgewerkt in alle local pools van 

het package, tenminste als daar de version of de kin voorkomt. Er zijn wat implementatie 

mogelijkheden: 

1. Er is een push mechanisme zonder dat een specifiek target is opgegeven door een gebruiker. 

Alle locations kunnen target zijn, en moeten bekend zijn in het climbexion systeem. 

2. Er is een pull mechanisme. Alle locations waarin deze attributes kunnen wijzigen moeten 

bekend zijn in de location die zijn pools up-to-date brengt 

3. Een push /pull combinatie: een push naar een universeel bereikbare location vindt plaats in 

de location waar een attribute is gewijzigd, een pull vindt (periodiek) plaats in iedere 

location. Daar worden de wijzigingen getrokken uit de universeel bereikbare location. Ieder 

package kan zijn eigen center location alloceren. Als een kin of version voor het eerst 

gekopieerd wordt vanuit de ene location naar de andere, dan wordt ook de center location 

bijgewerkt met die kin of met die version. Wordt daarna een attribute gewijzigd dan wordt 

dit doorgegeven naar de center location. Als een kin of een version niet te vinden is in de 

center location, dan wordt een lokale attribute wijziging ook niet doorgegeven. Deze derde 

methode zal waarschijnlijk worden geïmplementeerd, omdat die nauwelijks administratie 

vereist. 

4. Een universeel bereikbare plaats voor het doorgeven van version attributes, hoeft zelf geen 

version content te bevatten, alleen de identifier en de attributes volstaat. 

3. Packages. 

De centrale pools van een package staan op een location met een package gerelateerde URL Het 

package is onder meer identificeerbaar met behulp van deze URL 

4. Pools voor other-focused files. 

Wijzigingen moeten worden doorgevoerd in locale pools en in working-trees en info-trees. Ook 

hiervoor is een goede push/pull discipline nodig, en goede hulpmiddelen om de discipline te 

realiseren. 

5. Pools voor envelopes. 

Envelopes horen bij het subproject, bij de drawer constellation waarbinnen ze de wijzigingen 

transporteren, ze staan in een constellation gerelateerde pool. Ze kunnen ontstaan op een laptop, 

maar zodra hun inhoud publiek is moeten ze ook zijn geplaatst in een constellation pool. In het 

stadium “prepared” wordt in de constellation pool de envelope bijgehouden met de base items 

waarop gewijzigd gaat worden. Op de PC wordt een pool bijgehouden waarin ook de labored items 

staan. Bij de overgang naar “transfered” wordt de envelope in de constellation pool voorzien van de 

labored items. 

Pagina: 82 / 230



2.2 Begrippen 

6. Pools voor external envelopes. 

De external envelope ontstaat als een gewone envelope in een constellation pool, en wordt 

gekopieerd in een (master) project pool. Sheets kunnen waarschijnlijk ontstaan en blijven in een 

(master) project database, want er zijn allerlei query's op de verzameling sheets, bijvoorbeeld welke 

patches zijn er op baseline X van subsysteem S of welke patches kunnen er zijn op andere packages 

als ik baseline X van package S implementeer. Het database systeem waarin de sheets release 

supplements (en misschien ook die van releases) worden bewaard valt buiten de scope van 

Climbexion. 

7. Drawers. 

Een drawer wordt gealloceerd in een file system. Waarschijnlijk behoeven packages geen 

zelfstandige allocatie, maar kunnen ze deel uitmaken van de drawer. Een drawer kent een aantal 

structuren. In de eerste plaats is een drawer een lineaire structuur van packages. Een package heeft 

een content van elements, elements hebben een development course, en zijn mogelijk gegroepeerd 

per soort: files bij files, folders bij folders, cross references bij elkaar, package references bij elkaar. 

Dan is elk package te zien als een opeenvolging van changesets, en tenslotte is elk snapshot in een 

package te zien als een folder-tree, Een tag is een snapshot over alle packages in een drawer met een 

integrale folder tree. 

8. Parties, teams, users, projects registration. 

Misschien is het zinvol om hier ook een URL voor te reserveren. Iedere party heeft hiervoor een 

eigen administrator database. Daarnaast kunnen er registraties nodig zijn in de computers met 

drawers en pools. Systeembeheerders, bijvoorbeeld providers van services hebben namelijk ook hun 

eigen administrator, en security faciliteiten. 

9. Files, folders, en andere elements 

Ze worden geïdentificeerd door hun kin en hun drawer. Snapshots die naar buiten komen, in infotrees 

of working-trees krijgen hun eigen path-name. Ze worden over het algemeen lokaal 

geïdentificeerd. 

10. Tenslotte 

Van iedere resource bestaat minstens één kopie. Meerdere kopieën op meerdere plaatsen zijn 

mogelijk als de betreffende file of database server daarin voorziet. Voorlopig zullen hoogstens 

beperkte voorzieningen worden getroffen voor lokale kopieën die door Climbexion worden 

bijgehouden. 

Een vertaling van een package, een party, een team , een project of een combinatie hiervan in een 

URL gebeurt met gegevens die geleverd worden vanuit de administrator database. 

Het kan voorkomen dat een version in een satellite uiteindelijk niet overgedragen wordt, en mag 

vervallen als de satellite wordt opgeschoond of opgedoekt. Hetzelfde geldt voor envelopes. Dit 

vindt plaats in pools van de betreffende location. 

Pagina: 83 / 230



2.3 Metadata 

2.3 Metadata 

2.3.1 Inleiding 

De keuze om allerlei attributes te specificeren, de keuze om hier een course of metadata corrections 

voor bij te houden: dat is typisch het terrein van de kamergeleerde, het plezier om dit soort dingen 

te bedenken en te maken. Ik heb nu niets te maken met mensen die zeggen: “maar dat komt toch 

nooit voor in de praktijk dat dat fout gaat, je moet praktisch blijven”. (Terwijl we geen van beide 

eigenlijk beschikken over goed vastgelegde metingen). Het geheel aan doelstellingen voor 

Climbexion rechtvaardigt het gebruik van metadata courses of corrections. Wel verwacht ik een 

soort “self fulfilling prophecy”, als je attributes niet kunt wijzigen, dan bedenk je je wel twee keer 

voor je ze één keer invoert, als je ze kunt wijzigen dan zou je slordiger kunnen worden, en na een 

fout moet je ze dan wel wijzigen. Dan zeg je natuurlijk: “Goed dat het kan”. 

Zijn er alternatieven voor het verbeteren van attributes? Een event of een version met foute 

attributes kan worden opgevolgd door een event of version met correcte attributes. Een kin met een 

fout attribute kun je verlaten en verder gaan met een kin waarin het attribute wel goed is. Bij een 

fout element attribute zou je het element moeten beëindigen, om een nieuw element te beginnen met 

het correcte attribute. Hiervoor zou de uitspraak: “een element vertegenwoordigd de kin in de 

drawer”, niet langer gelezen mogen worden als: “een element vertegenwoordigd als enige de kin”, 

maar meer als “op enig tijdstip is er hoogstens één element dat de kin vertegenwoordigd”. Alleen 

al omdat ik de eerste lezing omarm, en de tweede verwerp, moet het mogelijk zijn om fouten te 

verbeteren. 

In principe gaat het om uitspraken: 

● in een event is een stuk historie vastgelegd, maar er worden ook een aantal uitspraken 

vastgelegd over dat event. 

● In een repository worden een aantal kins vastgelegd, maar ook een aantal uitspraken over de 

kins. 

● In een drawer worden een aantal files vastgelegd, maar ook een aantal uitspraken over de 

files. 

● In een pool worden een aantal versions vastgelegd, met uitspraken over die version. 

Voor deze uitspraken geldt: 

● Elke mogelijke uitspraak zou moeten kunnen wijzigen in elke mogelijke andere liefst 

zinvolle uitspraak. 

● Een uitspraak vandaag over een historisch feit gisteren moet mogelijk zijn. 

2.3.2 Attributes, soorten en maten 

Over file karakteristieken kan het nodige gezegd worden. Op de IBM mainframes waarop ik ooit 

werkte had een file karakteristieken als bloklengte, recordlengte, recordformat, access methode, 

wijze van space allocation, om maar eens wat te noemen, om zo'n file te kunnen maken moeten al 

die karakteristieken worden opgegeven. 

Momenteel is er de Mime standaard, waarin file-types gekarakteriseerd zijn met 2 trefwoorden, 

bijvoorbeeld voor een adobe acrobat file: application/vnd.adobe.edn. 

Doorgaans herken je het file-type aan de extensie van de file. In de property sheet van de file 

explorer van mijn windows (98) systeem zit een tabblad met file extensies, mime-types en 

Pagina: 84 / 230



2.3 Metadata 

dergelijke. Bij een bepaald type hoort een programma om zo'n file te wijzigen, een viewer, en 

mogelijk nog meer software. In het revision control system is een dergelijke lijst ook nodig. 

● We willen bijvoorbeeld weten of er een merge programma bestaat voor een bepaald filetype, 

of een pretty print formatting programma. 

● De build folders die opgeslagen worden in het revision control system kunnen worden 

geplaatst in een archief-file (bijvoorbeeld een .zip file of een .tar.gz file) bij opslag, en de 

archief-file moet (meestal) worden uitgepakt als ze in een working-tree of info-tree wordt 

gedownload: dus build archief folder is van een ander type dan een file of een gewone 

folder. 

● De folders in de NHSW folder tree zijn in te delen in soorten, sommige zijn er voor 

interfaces, anderen zijn een componenten set, weer anderen een enkele component 

enzovoort. De architecten hebben entity types voor ze bedacht. 

● revision control programma's die een snapshot van een drawer zichtbaar maken kunnen een 

viewer aanroepen, als de inhoud van een version moet worden bekeken. Hiervoor moet je 

het type weten. 

● Bij merging is er sprake van bases, neighbors en originals. Die moeten tot hetzelfde type 

behoren, en het type moet bediend worden door het merge programma. 

● Er zijn diverse conventies voor carriage/return characters in tekst files. De gebruikte 

conventie is een attribute van de version, Als wordt gedownload in een omgeving met een 

andere conventie, dan moet er automatisch worden geconverteerd. 

● In de documentatie van “Subversion” vond ik nog het volgende: een attribute om aan te 

geven of een file wel of niet “uitvoerbaar” is: dit is een Unix attribute. 

● Sommige typen file beginnen met een aanhef waarin Climbexion informatie moet plaatsen 

als datum, versie, naam van degene die de file gewijzigd of gemaakt heeft, en dergelijke. 

Andere file-types hebben hiervoor een property sheet (extended metadata). En sommigen 

hebben helemaal niets. We moeten weten of een file een dergelijke aanhef kan hebben, of 

een dergelijke property sheet. Dit is dan al één extra attribute. Om informatie te plaatsen 

moeten er mogelijk additionele attributes worden bijgehouden. Dit feature van revision 

control systems bestaat in ieder geval reeds sinds SCCS. Het is een klassieker. 

● Berucht in ons wereldje zijn endiaanse problemen met raw file formats, en ASCII 

/EBCDIC /Unicode conversies van teksten. Hopelijk zijn dergelijke conversies niet nodig, 

maar als ze nodig zijn, dan moet de betreffende codering samen met de file worden 

opgeslagen. Een revision control systeem heeft hier een bemiddelende rol tussen diverse 

omgevingen. 

● Software entiteiten (class, component, procedure en dergelijke) moeten overeenkomen met 

een file. Om aan te geven wat voor soort entiteit is opgeborgen in de file kun je een attribute 

gebruiken. Het file-type is dan bijvoorbeeld “C++ header file” en het entiteit type “abstract 

class”. Dit is van belang voor templates en pretty print programma's. 

● Typeringen kunnen van belang zijn om import limitations of export limitations te realiseren. 

2.3.3 Templates, wizards, pretty printing, macro's, en zo 

In enkele van de revision control systemen waarmee ik heb gewerkt gold: als je een nieuwe file 

introduceert, en (daarmee een nieuwe kin) dat zijn er twee mogelijkheden: 

● Je bied meteen een version aan. 

● Je registreert de nieuwe version in het revision control system die daarop een nieuwe 

Pagina: 85 / 230



2.3 Metadata 

maagdelijke working-tree file maakt met behulp van een template. 

Om een file aan de hand van een template te genereren is het meestal niet voldoende om een filetype 

te specificeren. Vaak moet de aard van de file moet ook gespecificeerd worden, bijvoorbeeld: 

dit Kword document is een interface beschrijving, of dit open-office document is een component 

beschrijving, of deze header file is een applicatie interface. De aard noemen we het “entity type”. 

Ik denk dat een template tool buiten Climbexion blijft. Het kan aan de hand van een model file of 

een model folder een initiële invulling maken. Enige wizard faciliteiten zorgen voor de juiste 

naamgeving van het element en mogelijk enige interne entiteiten. Het is de bedoeling om dit 

eenvoudig te houden, om aan de standaards van de architecten te voldoen. Wel zou zo'n tool 

optioneel de gegenereerde lege elementen moeten kunnen registreren in Climbexion, zodat hun kin 

gemaakt wordt. Anderzijds moeten ze ook zonder Climbexion kunnen werken, zodat ze behulpzaam 

kunnen zijn bij het overnemen van oude oplossingen in nieuwe structuren. 

Dezelfde gegevens kunnen in sommige gevallen gebruikt worden om tijdens “commit” een version 

in een working-tree door een pretty print programma te leiden dat de version formatteert volgens 

een ideaal, voordat die wordt vastgelegd volgens de standaards van de package owner. Versions die 

gedownload worden in een info-tree of working-tree kunnen wanneer dat gewenst wordt eveneens 

door een pretty print programma geleid worden, om te voldoen aan lokale standaards. Zoiets heb ik 

ooit meegemaakt geloof ik. 

Deze programma's horen ook niet bij Climbexion. Hun gebruik als filter kan voor Climbexion 

hinderlijk zijn. Versions worden waarschijnlijk geïdentificeerd door een hash van hun inhoud. De 

version die aangeboden wordt aan een filter heeft een andere identificatie dan de version die het 

filter verlaat. 

Het file-type kan ook gebruikt worden door een version control system om vast te stellen dat de file 

macro's kan bevatten, die revision control data plaatsen in een comment paragraaf, of dat de file een 

property sheet (extended metadata) bevat die ingevuld moet worden met revision control data 

volgens een template. In een comment paragraaf worden de waarden ingevuld die de macro's 

genereren. De waarden kunnen het best worden ingevuld als de version in een working-tree of infotree 

geplaatst wordt. De waarden worden het best verwijderd tijdens commit of als de version 

betrokken is bij een merge. Hiervoor geldt hetzelfde als pretty print: ze zijn hinderlijk omdat ze een 

moderne version identificatie hinderen. Advies: gebruik deze macro's niet in content. 

Voor de property sheet met extended metadata geldt mogelijk niet het probleem van de content 

hash. Speciale macro's specificeren welke repository data in de metadata van een working-tree, of 

info-tree file terechtkomt. Gebruik extended metadata in plaats van macro's in de code. 

Over het algemeen zullen de templates en de pretty print regels vastgelegd zijn per package. In 

configuratie files en template files die in het package zijn opgenomen. De hulpprogramma's zelf. 

kunnen eventueel staan in een tools folder van het package. Pretty print hoort eerder thuis in een 

build dan in een commit, samen met een eventuele static analyzer. 

De pretty print regels voor het plaatsen in info-tree en working-tree kunnen thuishoren in het toppackage, 

eventueel met bijbehorende tools. 

Andere begeleidende tools zijn merge programma's die gebruikt worden om parallel wijzigen en 

ontwikkelen mogelijk te maken, en misschien een static analyzer die een aanvulling is op een merge 

programma, om mogelijke fouten van een merge operatie te signaleren. Analyzers kunnen specifiek 

Pagina: 86 / 230



2.3 Metadata 

zijn voor file-types en/of entity types. Merge programma's moeten mogelijk in staat zijn om hun 

input versions rechtstreeks te lezen uit Climbexion. Hun output komt in de working-tree, en kan 

daar verder geanalyseerd en bewerkt worden, om daarna met commit in de repository opgenomen te 

worden. 

2.3.4 File-type 

Als je kijkt naar een filenaam, dan begint die met een pad: een reeks folder namen. Daarna komt de 

naam, en tenslotte de extensie. De extensie is rechtstreeks afleidbaar uit het file-type. Als je het filetype 

bijhoud, dan zou extensie geen onderdeel van de name horen te zijn, althans onder Windows. 

Er is best wel een probleem met een attribute als “file-type” Als het een attribute is van version en 

de waarde is fout, dan is er best kans dat je een heel traject aan versions in een course moet 

wijzigen. Dit duidt op een slechte normalisatie: “file-type” is een eigenschap van de file, met een 

course of development, en een course of metadata corrections. Er zou dus een development course 

item “File-type” moeten bestaan met een file-type attribute en een valid time attribute die 

corrigeerbaar zijn. 

Nu neem je een bestaande version en plaatst die in de tip van een file in een drawer, Deze file is 

bijvoorbeeld een Visio plaatje, en de nieuwe version, – ik noem maar iets –, is een Smartdraw 

plaatje, en is gekopieerd uit een file die een Smartdraw plaatje is. Als “file-type” een eigenschap is 

van de file, dan is hierna de version meertypig, in twee courses met ieder een eigen type. Dat kan 

natuurlijk niet, en deze mogelijkheid duidt op een slechte data structurering: “file-type” moet een 

eigenschap zijn van de version. Blijkbaar gelden beide regels. 

Voor de repository kies ik voor een implementatie die de combinatie van valid time en transaction 

time” vermijdt. Het overnemen van versions uit andere drawers moet probleemloos verlopen: een 

eigenschap als “file-type” wordt een directe eigenschap van de version, zodat de eigenschap gaat 

gelden voor de file als de version wordt geïntroduceerd. De course of development van de 

eigenschap in de file wordt – wanneer nodig –, met een algoritme bepaald. En er is het 

automatisme dat een nieuw gecreëerde version het huidige file-type erft van zijn voorganger in de 

course, tenzij anders vermeld. 

Mogelijk komen er handige opdrachten die attributes in een reeks versions in een traject van de 

course wijzigen, mocht een verbetering van het type nodig zijn Ook geldt: als zo'n attribute van een 

version verbeterd is en daardoor is gaan afwijken van een opvolger, dan moet dit in de course van 

de file gemarkeerd worden, als je die bekijkt. 

Als het attribute verbeterd moet worden, en de version is wijd uitgezwermd over de drawers en 

heeft op veel plaatsen opvolgers, dan moet er heel wat uitgezocht worden om alle courses in beeld 

te krijgen, die verbeterd moeten worden. Dat verbeteren kan dan weer met de handige opdrachten, 

dat wel, maar ja dan zijn er weer nieuwe verbeterde versies die uitgezwermd kunnen zijn, in weer 

andere drawers. Voorkomen is stukken beter dan genezen, maar als er moet worden genezen, dan is 

het goed als er middelen voorhanden zijn. 

De kans op onopzettelijke fouten is erg klein, omdat op de desktop de file extensie gebruikt wordt 

door allerlei software. De meeste fouten zullen waarschijnlijk aanloop fouten zijn, als een file 

geregistreerd wordt in Climbexion voordat de eerste version gemaakt wordt op de laptop of 

desktop, waarna de version gegenereerd wordt met hulp van een sjabloon. Er is dan nog geen 

uitzaaiing. Het is zeker dat er opzettelijke fouten kunnen worden gemaakt. Dat wordt bijvoorbeeld 

Pagina: 87 / 230



2.3 Metadata 

gebruikt bij het testen van Climbexion. Dus is er een rechtvaardiging voor het corrigeerbaar zijn van 

filetype. 

Introductie van een nieuw file-type in een bestaande course is niet triviaal voor de gebruiker, 

“commit” moet immers een (work) file met een andere extensie dan de voorganger koppelen aan 

een file. Het overnemen in een andere drawer is dan weer gemakkelijk, dan is er een kin match. 

Met de toekenning van het file-type attribute aan een version lijkt het bijna 100% mogelijk om de 

juiste typering te specificeren. Echter zonder al te goed je best doet, is het waarschijnlijk mogelijk 

om een version te maken die aan geen één type beantwoordt. Als ware informatie freak overweeg ik 

dan ook voor om naast het file-type “word document” het subtype “mislukt word document” te 

specificeren. Hier kun je problemen krijgen met het dualistisch karakter van file-type: zo'n subtype 

van een word document kan beter niet automatisch doorgegeven worden aan een opvolger. 

In het ene project kunnen tools gebruikt worden waarin een version goed functioneert, terwijl in 

een ander project dezelfde version een tool laat crashen. Het specificeren van de juiste subtypes 

voor files is daarom een kunst op zich zelf. 

Voorbeeld: 

File subtypes van “Microsoft word” zijn bijvoorbeeld: 

● “Microsoft word 95” 


● “Microsoft word 6.0” 

● “Microsoft word Failure” 

Oorspronkelijk hadden we slechts “Microsoft word”, en closed world subtypes “Correct en 

Failure” maar op een gegeven moment raakten we in de problemen. 

In project A wordt de extensie “doc” gegenereerd voor: 

● geen subtype attribute 


en de extensie “undoc” voor: 




In project B wordt de extensie “doc” gegenereerd voor: 

● geen subtype attribute 




en de extensie “undoc” voor: 


Normaal zal iemand, normaal zal Climbexion, proberen te voorkomen dat failures of niet 

verwerkbare versions worden doorgegeven van het ene drawer naar het andere, maar zolang het 

subtype attribute niet correct is bijgewerkt kan de falende version verspreid worden. 

Er is nog de mogelijkheid dat het ene (sub) project werkt met andere tools dan het andere. 

Pagina: 88 / 230



2.3 Metadata 

Bijvoorbeeld: het ene project gebruikt MS Word, het andere gebruikt Framemaker, het ene gebruikt 

Visio, het andere Igrafx Flowcharter. Er moet een mogelijkheid komen om een version te weigeren 

als het file-type niet wordt ondersteund. 

Versions komen in een pool. Als er voor een version slechts één pool is dan is er geen probleem. 

Helaas zullen er lokale pools zijn, en komt een enkele version op meerdere plaatsen voor. Het 

doorvoeren van file-type correcties zal dan geen eenvoudige zaak zijn. De correctie moet 

doorgevoerd worden in alle locaties waarin de versie zich bevindt. Als we aannemen dat de locaties 

waarin een package voorkomt een tree vormen, dan is er een automatisch push mechanisme dat het 

gewijzigde attribute naar de top duwt. En een pull algoritme waarmee locaties zich up-to-date 

houden. Dat laatste vereist enige discipline. 

Programmeer taal 

Als je een pascal programma een modula programma noemt, dan is dat een bewering die fout is, het 

is niet de werkelijkheid die geldt voor het programma waarop deze bewering slaat. In principe moet 

je dit kunnen verbeteren. Aangezien je een zo volledig mogelijke log wilt hebben van alles dat zich 

afspeelt in de repository, gelden voor dit soort wijzigingen transaction times. Programmeer taal 

attributes kunnen een course of corrections hebben. 

Om te beginnen zullen we eens kijken of het een attribute van de kin kan zijn. 

Een correctie die je vandaag maakt, geldt voor alle versions van de kin, ook die van gisteren. Een 

conversie van een programma naar een andere taal betekent een nieuwe kin. 

Dit zouden we kunnen verantwoorden, omdat we verwachten dat een overgang naar een andere taal 

ook het einde van Koala (als additioneel tool?) betekent. Een groot deel van de architectuur zou 

meteen mee veranderen, waardoor een “mixed language” overgang die begint met een één op één 

file conversie onwaarschijnlijk is. 

Maar een dergelijke toekenning van dit attribute aan een kin is geen garantie dat de versions 

werkelijk tot de geregistreerde programmeertaal behoren. Het is een “SOLL” voorschrift en niet een 

“IST” eigenschap. Eén enkele version in een verkeerde taal, en één in de goede, is een niet te 

repareren inconsistency als het een “ist” eigenschap betreft. Toch zijn er consequenties, want met 

behulp van de programmeertaal kan Climbexion de file extensie in een full path name genereren. 

Het is dan zeker niet een vrijblijvend voorschrift, en een verbetering kan sommige bestaande 

versions onbruikbaar maken. 

Als “programmeertaal” een attribute wordt van de kin, dan is het natuurlijk onzin om “mislukt 

fortran” op te nemen als mogelijke subattribute waarde, ook al is er misschien een version die een 

“denial of service” teweeg brengt tijdens het compileren. Ook verfijningen, zoals compiler version, 

zijn niet zinvol voor kins. 

Tot zover de kin studie. 

“Programmeer taal”, is een subset van “file-type”. We hoeven ze natuurlijk niet speciaal te 

behandelen. Mijn voorkeur gaat ernaar uit, om het file-type attribute toe te kennen aan versions, en 

“programmeer taal” niet speciaal te behandelen, zeker na deze overwegingen. 

Subtypes voor programma's kunnen worden gebruikt om hun afhankelijkheid aan te geven van 

target systems, zoals MIPS, ARM, TriMedia. Ook zijn er smaken als 8 bits, 16 bit, 32 bit, 64 bit 

processors, of endiaanse beperkingen, die voor sommige programma's gelden. Daarnaast zijn er de 

Pagina: 89 / 230



2.3 Metadata 

diverse compiler/linker systemen. Veel programma's zullen portable zijn, maar mogelijk is het 

zinvol om voor sommige versions aan te geven dat ze gebonden zijn aan een omgeving zodat 

gewaarschuwd kan worden als ze worden hergebruikt. 

Geldt voor programma's dat portabiliteit wel of niet bereikt wordt, voor andere files gelden regels 

van al dan niet bereikte compatibiliteit. Dit is niet hetzelfde. Programma's zijn individueel te 

beoordelen op portabiliteit. In een vakkundige omgeving worden er regels opgesteld voor taal 

features die je wel of niet moet gebruiken om deze portabiliteit te waarborgen. Er zijn tools die 

statische analyses uitvoeren op programma's om de portabiliteit te waarborgen. Gewone files, die 

geen programma zijn, en die gemaakt zijn door een bepaalde generatie van een tool, zijn meestal 

als groep te beoordelen op compatibiliteit met een andere generatie van het tool. Voor het ene filetype 

kunnen er dus andere regels en algoritmes gelden voor subtyping, dan voor het andere. 

Koala ontwikkeling 

Toen we begonnen maakten we van een Koala Component een plaatje: een rechthoek met op de 

rand de ingaande en uitgaande interfaces, en erbinnen grafische symbolen voor modules, switches 

en componenten. Die inwendige componenten hebben ook ingaande en uitgaande interfaces. 

Interfaces zijn binnen de rechthoek verbonden met elkaar, met modules en met switches. 

Koala Component 

Dit plaatje komt uit de Koala 

documentatie. 

Eerst maakten we ze volledig met de hand met Microsoft Visio, later 

kwam er een tool dat ze genereert. Het tool genereert een nogal lege 

xml file uit een cd file, als die er nog niet is. Het plaatje dat zo 

ontstaat ziet er niet uit. Pas als met de hand de symbolen en lijnen op 

hun plaats zijn gezet is er een redelijk ogend schema. Ook kunnen 

lijnen worden voorzien van hoeken, zodat we van een druk schema 

een printplaatachtig schema kunnen maken. Deze gewijzigde en 

nieuwe posities worden geregistreerd in de xml file. 

Het tool om de plaatjes te maken en te bekijken gebruikt de koala cd 

file en de gelijknamige xml file, die in dezelfde folder staat. Het 

vereist enige goede wil om de xml versies te zien als de opvolgers van 

van visio versies, immers de functionaliteit van het visio plaatje wordt 

niet bereikt met de xml file maar met de combinatie van een cd file en 

een xml file. Ook is er enige goede wil nodig, omdat het visio plaatje 

zuiver “self-focused” is, terwijl de xml file enigszins “other-focused” 

lijkt. 

Als je de situatie nader bekijkt dan zie je dat de xml file een referentie 

bevat naar de cd-file, dus de cd file wordt door het tool ingelijfd in de xml file om het plaatje te 

genereren, zoals een header file wordt ingelijfd in een C file om een object file te maken. Het blijkt 

dus toch een self-focused source file te zijn. Dus kunnen we besluiten om de ”MS visio" versies 

van de file op te volgen met “koala graphic” versies. 

2.3.5 Entity type 

Het entity type geeft de aard van een file of folder weer. Bijvoorbeeld: de file is een “component 

beschrijving”, of een “abstract datatype”, of een “test resultaat”. Of bijvoorbeeld: de folder is een 

component, de folder bevat public interfaces, of unit-tests. 

Pagina: 90 / 230



2.3 Metadata 

Het is niet goed voorstelbaar dat je één kin hebt waarvan sommige files of versions een component 

beschrijving zijn en anderen een test resultaat. Soms is het misschien dubieus of je een file op een 

bepaalde manier mag voortzetten of dat je een nieuwe file en daarmee een nieuwe kin moet 

beginnen. Maar als er één attribute in aanmerking komt om een eigenschap van een kin te zijn dan 

is het wel het entity type. Versions met een verschillende aard horen niet in dezelfde file of in 

dezelfde kin. Het is wel een typisch “soll” attribute, gewoon omdat het een intentie is van de kin en 

van degene die de kin maakte die niet automatisch geldt voor elke version. Je kunt daarin fouten 

maken. In ieder geval kan ik deze fouten opzettelijk maken, dus mogelijk kan het ook per ongeluk 

gebeuren. 

Correctie is nuttig als je per ongeluk een verkeerde entity type waarde hebt geselecteerd of getypt 

bij het aanmaken van de kin, maar is niet mogelijk na commit van een version met een verkeerde 

aard (misschien moet je bij een version in een attribute aangeven dat het item een vergissing was). 

Moet je een course bijhouden van de corrections? Ach, waarom niet, nu we in zijn algemeenheid 

hiervan gebruik maken. 

Een toepassing van “entity type” is ongetwijfeld het gebruik in import limitations. Een andere 

belangrijke toepassing is de mogelijkheid om templates te bieden. Templates zijn niet slechts van 

belang voor files, maar zeker ook voor folders. Hun type bepaald vaak al welke files en subfolders 

erin moeten of mogen voorkomen. Koala is een programma dat tijdens build begrenzingen vast 

stelt, voor dependency lists, en van de sources die nodig zijn om een executable, te maken. Hierbij 

wordt gebruik gemaakt van het entity type van folders, om packages, component folders, interface 

folders, tools folders, test harness folders, scoop folders, en dergelijke te herkennen. Momenteel 

wordt daarvoor de naamgeving en structuur van folders gebruikt, en natuurlijk de files die erin 

staan. Legacy en verschillen tussen teams kunnen een belasting gaan vormen die mogelijk met 

entity metadata is te voorkomen. 

Ik denk dat er een probleem kan zijn met entity type. De levensduur van een package, en daarmee 

de levensduur van een kin is veel groter dan die van een project. Dat betekent minstens dat de 

codering van een entity type kan veranderen. Al was het alleen maar omdat een uniforme codering 

binnen een master project gewenst kan zijn. En anders zijn er wel internationale standaards, of tools 

die een bepaalde codering eisen. 

Mogelijkheden: 

● Meerdere coderingen van het entity type moeten mogelijk zijn, om steeds te voldoen aan een 

modern coderingssysteem. Het lijkt erop dat een entiteit attribute moet gaan bestaan uit het 

paar (code van de standaard, code van de entiteit). Een project kiest een standaard. 

● Bij een package wordt een codering bijgehouden, die aan geen andere standaard voldoet dan 

die van het package. Een stelsel entiteit codes kan alleen maar uitbreiden, maar niet 

wijzigen. Binnen een project wordt een vertaling gemaakt ten behoeve van tools, zodat de 

metadata in de working-tree voldoet aan de project eisen. Maar de metadata in de kins 

voldoet aan de package standaards. 

Heeft de kin alleen maar “soll” eigenschappen? De eigenschap dat een kin gebonden is aan een 

package is een “ist” eigenschap. Elements en versions behoren onvervreemdbaar tot het package 

omdat hun kin ertoe behoort. Het gegeven dat de kin aangemaakt is door Joost is een “ist” 

eigenschap die niet geldt voor al zijn elements en versions. 

Pagina: 91 / 230



2.3 Metadata 

“Soll” en “ist” zijn begrippen uit de administratieve organisatie en diens interne controle, waar 

een actuele werkelijkheid (“ist”) wordt vergeleken met een norm (“soll”). In het boek “Information 

modeling and Relational Databases” van Terry Halpin en Tony Morgan vond ik de begrippen 

“deontic” en “alethic” (niet helemaal) in plaats van “soll” en “ist” voor het typeren van 

“business rules”. Bijvoorbeeld: juridische wetten zijn deontic, en natuurkunde wetten zijn alethic. 

In feite heb je alleen bij een deontic rule een norm (soll) en een werkelijkheid (ist) die ermee 

vergeleken kan worden; bij een alethic rule is er uitsluitend een eigenschap van de werkelijkheid, in 

dat geval interesseert de interne controle niet voor “ist”, want er hoeft niet gecontroleerd te 

worden of aan een norm is voldaan. Nog even in Wikipedia gekeken. Modale logica: redeneren met 

de modaliteiten “possible” en “necessary” en “contingent” is alethic logic, en redeneren met de 

modaliteiten “obliged” en “forbidden”, “permitted” is deontic logic. De begrippen “SOL” en 

“IST”, die ik gebruikte zijn dus niet terecht. Beter is het om ze deontic en alethic attributes te 

noemen. 

2.3.6 Restricties op kins 

Bij een kin zouden lijstjes van toegestane folders of toegestane names kunnen worden bijgehouden, 

met het doel de package varianten in de diverse subprojects onderling vergelijkbaar te houden, niet 

slechts voor Climbexion, die met kins kan werken, maar ook voor stervelingen die met names en 

folder names werken. Om name en folder wijziging te realiseren is er overleg en overeenstemming 

nodig tussen de teams die een package beheren. In principe heeft men hier geen speciale 

voorzieningen voor nodig. Afspraken zouden voldoende moeten zijn. Mocht je er toch toe besluiten 

om op deze wijze enig conservatisme te willen afdwingen, dan zou je kunnen overwegen om een 

kin door stadia te loodsen. In het “born” stadium, als de kin net is gerealiseerd kunnen name en 

folder reference vrij wijzigen. Later als de kin wordt aanvaard door de community, treedt het 

“registered” stadium in, en gaan de lijstjes gelden, en kunnen normale gebruikers slechts wijzigen 

voor zover de lijstjes dit toestaan. De lijstjes zelf worden bijgehouden door een autoriteit. In plaats 

van lijstjes zouden eventueel “regular expressions” kunnen worden gebruikt. Dergelijke lijstjes zijn 

typisch metadata. Het eigenaardige van dergelijke restricties is dat ze niet gelden voor de bestaande 

course items in de elements, maar uitsluitend voor nieuwe name en folder wijzigingen. 

2.3.7 Classifications ten behoeve van export limitations 

Classifications voor de geheimen van NXP zouden aan kins kunnen worden toegekend, maar 

misschien is er enige flexibiliteit nodig en zouden uiteindelijke definities kunnen worden 

vastgesteld in de subprojects, en dan gelden voor de elements in de drawers. De openheid of 

geslotenheid in het ene project kan afwijken van die in een ander project, en een wijziging in het 

beleid is niet automatisch van toepassing op alle bestaande subprojects. Ook bij gemeenschappelijk 

beleid is er flexibiliteit, als de uitvoering in het éne project kan verschillen van de uitvoering in een 

ander project. 

De scoop van een classificatie system is dan ook het subproject. Binnen een subproject worden 

classifications toegekend, die uiteindelijk resulteren in export limitations. Voor zover classifications 

Pagina: 92 / 230



2.3 Metadata 

worden toegekend aan versions, of elements betekent dit dat de betreffende attributes het subproject 

niet verlaten, maar dat ze de uitgangen van het subproject bewaken. Een subproject waarin een 

package geïmporteerd wordt mag die in principe niet doorgeven aan derden. Dus een geïmporteerd 

package is in zijn geheel strikt geheim. 

Het is te verwachten dat classifications simpel zijn, twee of drie, hooguit 4 classificatie niveaus is 

waarschijnlijk alles dat nodig is. Bijvoorbeeld: er zijn “ingewijden” die alles mogen zien, versus 

“buitenstaanders” die maar een beetje mogen zien. Binnen NXP zou de kaste van “audio/video 

bewerkers” meer ingewijd kunnen zijn dan de kaste der “driver makers”, die weer meer mogen zien 

dan “klanten”. Ingewijden zouden bijvoorbeeld “geheime” en “openbare” files mogen zien, en 

buitenstaanders alleen “openbare”. Er zijn dus classifications die betrekking hebben op geheimen 

van NXP die de distributie binnen het masterproject beperken. De beperkingen hoeven niet voor 

alle teams hetzelfde te zijn 

Verder is er mogelijk een set files, waarvan je niet wilt dat die opduiken in een sister-project, omdat 

dit het vertrouwen van een partner beschaamt. Een geheim van een partner is geïmplementeerd in 

de software van NXP. Dit betekent een een tweede classification codering. De classification kan de 

export naar sister projects en reference design project aan banden leggen. Niet elk sister project zal 

dezelfde beperkingen hebben, bijvoorbeeld sister projects voor dezelfde klant kunnen het geheim 

vrij uitwisselen. 

Deze classification kan bovendien de distributie binnen een masterproject beperken, waardoor niet 

alle teams alle files krijgen. 

Classifications moeten op orde zijn als een baseline wordt samengesteld, maar ook, als een 

specifieke info-tree (uit een expose-drawer) worden samengesteld ten behoeve van debugging door 

een ander team, of misschien voor een demo. Ook als wijzigingen doorgegeven worden met behulp 

van external envelopes moeten de classifications blijven gelden. Het gebruik van envelopes van 

wijzigingen in een sister project zijn ook onderhevig aan de classification toets. 

Voor classificaties geldt dat het beleid (de classifications) ten aanzien van geheimen handmatig 

moet worden vastgelegd in of bij de repository. Dit kan bijvoorbeeld in de team-drawer voor files, 

en package references, want dit is de bron, vanwaaruit de andere drawers worden gevuld. Primair 

gelden de attributes daar voor de elements: files en package references. 

Voor het propageren van classifications naar andere drawers, geldt dat dit het beste kan met version 

attributes. Dus classification attributes moeten ook (automatisch) aangebracht worden als attributes 

van de versions, zodat ze gemakkelijk gepropageerd kunnen worden naar andere drawers. 

Versions met een classification moeten deze (automatisch) propageren naar nieuwe versions die 

eruit ontstaan. 

Tenslotte geldt dat geclassificeerde versions en package references niet mogen worden gekopieerd 

naar omgevingen (pools, drawers, working-trees, viewtrees) die lager geclassificeerd zijn. Een en 

ander kan betekenen dat allerlei tools en file systems onder controle staan van security 

mechanismen. Mogelijk is die situatie niet bereikt in de eerste releases van Climbexion. 

Van een package met classifications wordt normaal gedurende de looptijd van het project een 

library met binary object code of een executable met binary code beschikbaar gesteld aan 

buitenstaanders. Alle source code is gecompileerd om de binary code te maken. Ergens binnen de 

binaries, die zelf openbaar zijn, zitten –, hopelijk onwaarneembaar –, de geheimen. Daarnaast 

Pagina: 93 / 230



2.3 Metadata 

worden sources ten behoeve van de application interface beschikbaar gesteld, en gebruikersdocumentatie. 

Van de sources van de binary code en van hun ontwerp en implementatie 

documentatie wordt mogelijk een deel beschikbaar gesteld ten behoeve van debugging en analyse, 

voor zover dit geen geheimen onthult. Deze werkwijze is een praktische randvoorwaarde. Stel de 

binary ontbreekt, en een source file wordt op zeker tijdstip (maar wel voor de looptijd van de file) 

geheim verklaard, dan moet er terstond een binary van de file gemaakt worden voor alle snapshots 

waarin die ontbreekt. Dit is additioneel fragmentarisch werk, dat erbij komt als classifications 

wijzigen. Dit geldt voor classifications binnen het masterproject, voor classifications voor sister 

projects geldt dit niet, want een package voor een sister project wordt niet letterlijk overgenomen, 

en de benodigde binaries worden binnen het sister project zelf gemaakt. 

Handmatig classification attributes toekennen aan files: Een wijziging van een classification 

betekent een wijziging voor alle versions in de course of development van de file. Zo'n wijziging 

kan een correctie zijn van een onjuiste classificatie, maar vooral ook een beleidswijziging. Er is dus 

sprake van een veranderde werkelijkheid. Maar, het is geen intentie van de repository om iets te 

registreren over een beleid, het is de intentie om iets vast te leggen over een file. Onder normale 

omstandigheden participeren classification event items niet in een (valid time) snapshot, maar wordt 

altijd de tip van de (transaction time) course van classifications gebruikt, ook op oude snapshots van 

files. Het attribute heeft dus een valid time gelijk aan de levensduur van de file waarop hij 

betrekking heeft, en een transaction time die ongeveer overeenkomt met een bepaald beleid, ten 

aanzien van geheimen. 

Pagina: 94 / 230 

classification update in een package op een welgekozen snapshot 

Weliswaar is het snapshot gekozen, maar de attributes die bijgewerkt worden zijn attributes van 

het element.



2.3 Metadata 

Handmatige classifications toekennen aan folders en files. Een package snapshot wordt gebruikt om 

classifications toe te kennen. Top-down worden classifications toegekend aan folders, met 

toenemende geheimhouding. In feite worden de classifications toegekend aan de inner-reach van de 

folders. Enerzijds heeft men zo een systematische werkwijze, anderzijds, nu folders een 

classification attribute hebben, kunnen files die nieuw gecreëerd worden, het attribute erven van de 

folder waarin ze ontstaan. Misschien wordt deze exercitie enkele malen herhaald gedurende de 

looptijd van een project, want in nieuwe snapshots kunnen nieuwe files en folders staan. Mogelijk 

wordt dan meer fragmentarisch gewijzigd, top-down vanaf subtoppen. 

Gedurende de looptijd van een subproject kunnen files verplaatst worden van de ene naar de andere 

folder. Dus niet in elk snapshot zal gelden dat een file minstens zo geclassificeerd is als de folder 

waarin hij staat. Een export query selecteert de versions die niet te geheim zijn, en de folders die 

dan niet leeg zijn, dus de query maakt geen gebruik van folder classifications. 

Merk op dat er 2 rollen zijn van het attribute “classification”. Een classification die toegekend wordt 

aan een file of een package reference geldt voor het element: het element wordt wel of niet 

beschikbaar gesteld. Het attribute toegekend aan een folder heeft een heel andere rol: het wordt bij 

sommige gebeurtenissen gebruikt om de waarde door te geven aan een file of package reference in 

zijn inner-reach maar geldt niet voor de folder. 

(In plaats van classification levels, zou mogelijk ook gewerkt kunnen worden met permission 

levels, en dus afnemende geheimhouding naarmate je lager in de tree komt. De hele tree inhoud is 

dan alleen voor ingewijden, en sommige delen zijn ook voor buitenstaanders.) 

Waarom zo ingewikkeld? Ik hoop dat de top-down methode systematisch is. Ook hoop ik dat de 

methode navolgbaar is, zodat review en kritiek mogelijk zijn. 

Is dit nu alles? Nee, want niet alleen beleid kan veranderen, maar ook de software. Een module 

zonder geheimen kan wijzigen in een module met geheimen, als een verbeterd algoritme wordt 

geïmplementeerd. Het resultaat kan zijn dat het onmogelijkheid wordt om elk snapshot te beveiligen 

met dezelfde classifications. Een toekenning van classifications is dan adequate voor het ene 

snapshot maar is te restrictief of te ruimhartig voor een ander, en er is geen bevredigende 

gemeenschappelijke toekenning. 

De onderstaande studie is bedoeld om tot een beheersbare methode te komen die gebruik maakt van 

een course of development van classifications, zoals die er zijn voor versions, names, en folder 

references. 

Zodra een element door wijziging geheim wordt, of openbaar, wordt er vlak voor het course 

item dat de nieuwe version in de course plaatst een course item opgenomen dat een anchor is 

waarin voor de toekomst van de course het classification attribute wordt bijgehouden. Dit 

anchor kan een course of corrections ondergaan waardoor hij verplaatst wordt in de course 

of development van het element, hij kan geïntroduceerd worden of vervallen. Het anchor 

refereert aan een security change die herkend wordt door titels als: “de introductie van een 

privaat 3d-comb filter algoritme”, of “de overgang naar een openbaar stroomlijn algoritme”. 

Een reversed list toont per security change de betreffende anchors in de elements, zodat er 

een controle is op juistheid, volledigheid en ontwikkeling. Het anchor noemen we een 

classification-anchor en de security change noemen we een classification-set. De set is de 

verzameling elements waarin de nieuwe anchors staan. 

Pagina: 95 / 230



2.3 Metadata 

Als een nieuw element gemaakt wordt, dat wordt er ook een classification-anchor gemaakt. 

Dit kan een anchor zijn met of zonder referentie naar een classification-set. Alle latere 

classification-anchors hebben altijd een referentie naar een set. Het invoeren van een 

classification-set moet tijdig gebeuren, vóór of samen met de changeset die een geheim 

introduceert, tenminste als het er om gaat een geheim te introduceren, om een openbaarheid 

te introduceren kun je beter te laat zijn dan te vroeg. 

Het lijkt erop dat classification-sets op snapshots en tags lijken, wat betreft de inclusie van 

changesets. Maar snapshots en tags “kijken” terug in de tijd naar de meest recente event 

items van courses, terwijl classification-sets vooruit kijken, “van nu af aan gelden de nieuwe 

classifications”. Dus de timestamp van de classification-set wordt virtueel afgerond zodat 

die ouder is dan de revision waarop hij duidt, maar jonger dan de vorige revision. Het ziet 

ernaar uit dat classifications_sets worden bijgehouden buiten de changesets. 

Ik zal kort 2 scenario's beschrijven. In het ene houdt een expert alle classifications bij, en in het 

andere houdt het team de classifications bij, maar zorgt een expert voor een basis en correcties. 

Expert 

De expert is volledig en als enige verantwoordelijk voor het toekennen van classifications. 

Een expert voert de top-down exercities uit, en creëert classification-sets. Als een teamlid 

een file of folder verplaatst (door de folder reference te wijzigen), dan behoudt die de 

classifications die toegekend zijn door de expert. 

Team and Expert 

Ieder in een team is verantwoordelijk voor het uitvoeren van het beleid ten aanzien van 

geheimen. Bij de start van een subproject worden de betreffende packages voorzien van 

extra folder paren waarvan de naamgeving aangeeft welke classification er geldt. Ze heten 

bijvoorbeeld “secret” en “disclosed”. Een element start zijn leven in de inner-reach van zo'n 

Pagina: 96 / 230 

classification-set, classification anchor



2.3 Metadata 

folder. Mocht er een foute classification geconstateerd worden dan wordt wordt de file 

verplaatst naar de inner-reach van de andere folder, met de transaction optie: “classification 

correction”, waardoor de classification van het element wordt bijgewerkt in het bestaande 

classification-anchor . Als een file of (groepje files) verplaatst wordt met de optie: 

“classification development”, dan wordt een nieuwe classification-set gecreëerd, en voor de 

betrokken elements classification-tags. De file en folder structuur van een package in de tip 

van de drawer bepaalt de classifications van de files in de meest recente classification-set. 

Daarnaast is er nog een expert nodig voor review en correctie van classifications in 

classification-tags, voor het tussenvoegen, verplaatsen en laten vervallen van classificationtags 

in elements, het doorvoeren van beleids-wijzigingen en dergelijke. 

Naast het vastleggen van het beleid is er nog het propageren van classifications. Als een version 

wijzigt ontstaat een nieuwe version, met de classification van het origineel. Als een version ontstaat 

uit twee andere versions, dan is de nieuwe classification (automatisch) minstens zo restrictief als de 

classifications van de twee. Dit moet gerealiseerd worden voor wijzigingen in satellites en workingtrees. 

Het liefst zo dat het propageren van de classification onontkoombaar is. De automatische 

propagatie gaat uit van een worst-case aanname, die mogelijk nog gecorrigeerd moet worden. Als 

nieuwe versions de team-drawer binnenkomen, dan moet hun classification in overeenstemming 

zijn met die van de file, anders moet er (handmatig) een conflict opgelost worden. 

Zie:Dorothy E. Denning: “A Lattice Model of Secure Information Flow”. Communications of the 

ACM May 1976, Volume 19 number 5. 

Het kopiëren naar export-drawers en expose-drawers gebeurt volledig op version en package 

reference classifications. Mochten er daarna nog classification corrections komen dan geldt: 

“jammer dan”. Hoogstens kan daarna nog een snapshot aangemaakt worden, dat qua classifications 

correct is. 

In de folder tree van NHSW komen de folders “public” en “private” voor met een andere betekenis 

dan de folders “secret” en “disclosed” die ik hier introduceerde. “Public”: de components en 

interfaces in de inner-reach mogen worden gebruikt in andere packages, “Private”: de 

components en interfaces in de inner-reach mogen niet worden gebruikt in andere packages. Het 

betreft hier information hiding ten behoeve van maintainability, en reliability. De informatie 

(component en interface descriptions) in “private” folders is verborgen voor software in andere 

packages, maar niet voor mensen in andere subprojects. 

2.3.8 Original en neighbor 

Stel je gebruikt een envelope uit een ander project om een wijziging door te voeren, dan krijg je min 

of meer automatisch de attributes “original” en “neighbor” ingevuld bij het de element reference in 

de eigen envelope (zie voor deze begrippen: 2.4.1). Als er bijvoorbeeld 5 files in de envelope staan 

dan kunnen de attributes in 5 maal ingevuld zijn. Nu kun je voor sommige programma's besluiten 

om niet merge samen te voegen, maar om een andere oplossing te programmeren. Dan kan het zijn 

dat je de attributes wilt uitgummen. Ook als je wel merge gebruikt maar naderhand ook nog wijzigt, 

dan wordt het mogelijk dubieus of de attributes nog wel gelden. Aan de andere kant is het misschien 

wel zo dat je deze attributes wilt opgeven, terwijl je er geen merge tool voor hebt gebruikt. Kortom, 

Pagina: 97 / 230



2.3 Metadata 

je moet ze kunnen verbeteren. 

Het is wel zeer verleidelijk om wijzigen toe te staan zonder transaction times bij te houden, immers 

dit speelt zich voornamelijk af als de envelope ontwikkeld wordt in een satellite, die heeft immers 

een typisch een werkplaats karakter. Toch schakel je dan bij voorbaat een stukje logging uit. 

Bovendien kan het natuurlijk ook voorkomen, dat iemand zijn wijzigingen overdraagt, en twee 

nachten later opeens wakker schrikt, overeind zit in zijn bed en weet: “original en neighbor zijn fout 

ingevuld”. Dus net als wijzigingen van de attributes van andere entiteiten hoort er een transaction 

time bij. 

Nu is het zo dat één van mijn uitgangspunten is dat een persoon of een groep zijn eigen proces 

vastlegt en vervolgens zijn product presenteert aan anderen Het volledig vastleggen van de 

ontwikkeling van de envelope in een satellite is typisch informatie over het proces. Deze informatie 

moet samengevat worden tot product informatie bij een overdracht, dus alleen het uiteindelijke 

resultaat wordt overgedragen, en niet de ontwikkeling tot het uiteindelijke resultaat. 

Een envelope is toch iets dat als één geheel pendelt tussen satellites en center-drawer en eventueel 

een transfer drawer. Dus toch maar geen transaction times voor attributes. Voorlopig geef ik dus toe 

aan de verleiding. 

2.3.9 Base en labored 

In envelopes kent men een reeks die bestaat uit “base” event items, die een basis leggen voor 

wijzigingen, en “labored” event items die de voorgaande base opvolgen. In principe geldt hiervoor 

wat gold voor “original & neighbor”. We zullen voorlopig geen transaction times bijhouden, maar 

de labored version overschrijven. 

2.3.10 Kin references 

Een file verwijst naar een kin. Het kan voorkomen dat iemand een nieuwe file, en dus een nieuwe 

kin begint, en later blijkt dat dat er al een kin bestaat voor de file. Dan moet je de reference van de 

file naar de kin kunnen verbeteren. Ook, als een kin reeds bestaat, en een file is erop gebaseerd, en 

later blijkt dat de file verwijst naar de verkeerde kin, dan zou je de verwijzing moeten kunnen 

verbeteren. 

Dergelijke fouten kunnen zijn uitgezwermd over veel drawers, het verbeteren is dan geen fluitje van 

een cent. 

Misschien heeft het zin een kin naar een ander te laten verwijzen als blijkt dat ze hetzelfde zijn. 

Deze verwijzing zou dan bij gelegenheid, (bijvoorbeeld als onderdeel van een synchronisatie) 

kunnen resulteren in een update van het file attribute. Actieve drawers die een synchronisatie 

ondergaan komen dan vanzelf aan bod voor een update. 

2.3.11 Attributes van drawer, package, pool, machine 

Drawer 

Een drawer speelt een rol in een constellation. Rollen zijn: “center”, “transfer”, “satellite”. Zowel 

rol als constellation zijn attributes. In wezen is constellation de referentie naar centrale pool waarin 

Pagina: 98 / 230



2.3 Metadata 

envelopes bewaard worden. Een constellation heeft dus een URL. In satellites kan er behoefte zijn 

aan een private pool, waarin een envelope verkeert totdat er een bepaalde kwaliteit bereikt is, en 

mogelijk dient de lokale pool ook om een kopie te kunnen gebruiken, als je niet op je werkplek 

bent, en afgesloten van het intranet. De referentie naar de lokale pool is ook een attribute. 

Moet je deze rol en deze referenties kunnen wijzigen? In principe wel, maar de samenhang moet 

gerealiseerd zijn als je met de constellation werkt (om deze attributes te wijzigen wordt de drawer 

als het ware even “uit de lucht” genomen, soms moet dit mogelijk voor de hele constellation). Moet 

je de historie bewaren? Liefst wel, maar bij historische gegevens kan de samenhang waarschijnlijk 

niet gelden, als bijvoorbeeld een envelope pool, of een center-drawer wordt verplaatst dan wijst een 

vorige URL nergens naar. 

De constellation pool waarin envelopes bewaard worden wordt genoemd in meerdere drawers, en 

hetzelfde kan gelden bij lokale envelope pools. Als de envelope pool verplaatst wordt dan moet dit 

bij alle drawers worden aangepast. 

Heeft een drawer een kin? Voorlopig zie ik daar geen directe toepassing voor. 

Attributes van een package 

Er zijn de references naar lokale pools voor versions, kins, other-focused files en dergelijke. Deze 

referenties moeten zo worden bijgehouden dat de samenhang gehandhaafd blijft. Al deze references 

zijn URL's. 

Attributes van pools 

Vaak refereren ze naar een centrale pool, die nuttig is bij de distributie van wijzigingen. 

2.3.12 Tenslotte 

Uiteraard hoort bij een transaction, of het nu een update van een attribute betreft of de update van 

een element, de naam of user-id van degene die de wijziging uitvoert. Dit is een belangrijke reden 

om courses of metadata corrections bij te houden voor attributes: de wie,wat, waar, wanneer reden. 

Waarschijnlijk moet er een zekere eenheid bestaan binnen een masterproject. Voor attributes als 

“file-type”, “entity type” en dergelijke, kunnen het best standaards worden gespecificeerd zowel 

wat betreft de waarden, als ook de toekenning van het attribute aan een climbexion entiteit. Teveel 

verschillen tussen packages leiden waarschijnlijk tot meer werk bij het opstarten van een project. 

Als je erover nadenkt dan valt het op dat er eigenlijk niets triviaal is aan de attributes die je wilt 

opnemen bij kins, files, event items, en versions, enzovoort. Ze zijn moeilijk op één hoop te gooien, 

qua wijze van bijhouden, wijze van doorgeven, en wijze van gebruik. 

Pagina: 99 / 230



2.4 Werkwijzen 


2.4.1 Merging 

Basics 

Er zijn meestal twee programma's betrokken bij merging, een difference program en een merge 

program. Het merge program gebruikt de resultaten van het difference program. Tegenwoordig is er 

ook vaak een interactief (GUI-based) programma, waarmee naast merging ook editing mogelijk is. 

Er zijn drie versions van een kin betrokken bij een merge. Een original O en twee nieuwe varianten 

N1 en N2. De wijzigingen om van O een N1 te maken kunnen worden bepaald met het difference 

program. We noemen deze wijzigingen diff(N1,O) Ook diff(N2,O) wordt bepaald. Het merge 

program moet nu de combinatie diff(N1,O) en diff(N2,O) aanbrengen op O. Dit mag echter alleen 

als er geen conflicterende overlap is tussen beide. 

Stel 2 files worden met elkaar vergeleken met een difference program en ze komen voor 95% 

overeen. Aan het 3-way merge programma geven we een null file op als original van deze 2 files. 

Pagina: 100 / 230 

Simpele interactieve merge 

Conflict tijdens merge




Dan hebben we 100% overlap en dus potentieel 100% conflict. We gaan dan additionele analyses 

uitvoeren op de twee files om een refinement van de conflicts te vinden. 

In het version control programma dat we gebruikten ging merging al mis door de aanhef van de 

source files. Ze begonnen met conflicten. 

/* 

* Copyright(C) 2002 Koninklijke Philips Electronics N.V., 

* All Rights Reserved. 

* This source code and any compilation or derivative thereof is the 

* proprietary information of Koninklijke Philips Electronics N.V. 

* and is confidential in nature. 

* Under no circumstances is this software to be exposed to or placed 

* under an Open Source License of any type without the expressed 

* written permission of Koninklijke Philips Electronics N.V. 

* 

*############################################################ 

*/ 

/*! 

* \file avpppy_mpow.c 

* 

* \brief - 

* 

*/ 

/*----------------------------------------------------------* 

* 

* %version: 4 % 

* %date_created: Sat Aug 26 17:48:26 2006 % 

* %date_modified: Mon Sep 17 14:26:31 2007 % 

* %derived_by: memphis % 

* 

* 

*############################################################ 

*/ 

Conflicts zie je in "version", "date_modified", "derived by" als je een merge uitvoert. De default 

oplossing van het merge programma: twee regels "version", twee regels "date_modified", en twee 

regels "derived by", dus je moest wel ingrijpen. De opensource adepten zullen wel zeggen: "Dat 

komt er nou van" 

Stel bijvoorbeeld dat er een original version is, die in twee files (iedere file in zijn eigen drawer) 

voorkomt en dat in de course van beide files exact dezelfde wijziging is aangebracht, dan behoort 

de wijziging tot de overlap. Nu zou de overlap wel eens volledig conflict-vrij kunnen blijken te zijn 

bij additionele analyses. 

We veronderstellen dat een (original) file bestaat uit een reeks atomen (bijvoorbeeld regels), en dat 

een difference analyse ontdekt welke atomen veranderd zijn, of verdwenen, of verplaatst, of dat er 

atomen zijn toegevoegd tussen 2 atomen van O. Het kan zijn dat diff(N1,O) en diff(N2,O) beiden 

een wijziging tonen op hetzelfde atoom in O, of dat beiden laten zien dat er tussen dezelfde 2 

atomen toevoegingen zijn geweest. Dergelijke wijzigingen noemen we de overlap. 

Bij een unattended merge mag één der files N1 of N2 dominant worden verklaart. Als N1 dominant 

Pagina: 101 / 230




is dan wordt N1 new bewaard. Het merge programma bepaalt de wijzigingen zonder overlap van N1 

en die van N2. Dan wordt N1 new gemaakt door de wijzigingen zonder overlap van N2 en alle 

wijzigingen van N1 aan te brengen op O. Ook N2 new, wordt gemaakt door de wijzigingen zonder 

overlap van N1 en alle wijzigingen van N2 aan te brengen op O. Dan bepaalt diff(N1 new,N2 new) de 

conflicten, en de gewijzigde dominante file wordt behouden. 

Een veel preciezere beschrijving van een drieweg merge en conflicts vond ik in Wikipedia: 

“A Formal Investigation of Diff3” van Sanjeev Khanna, Keshav Kunal, and Benjamin C. Pierce. 

Een theorie voor wijzigingen en het overnemen ervan vond ik in het Darcs manual: 

http://darcs.net/manual/ het hoofdstuk: "Theory of patches" 

Mijn beschrijving is misschien leuk voor het begrip, maar echte merge en diff programma's hebben 

meestal een veel sneller algoritme dan ik hier beschrijf, en bovendien soms ontzettend veel opties, 

onder meer om defaults aan te nemen bij conflicts. 

Vaak wordt een merge interactief uitgevoerd door een ontwikkelaar met een programma dat 2 files 

vergelijkt: N1 en N2. De ontwikkelaar wijzigt één van de twee files door er wijzigingen van de 

ander in aan te brengen. Het programma kent niet de original file, maar de ontwikkelaar wel. Die 

moet weten wanneer er een conflict is, en welke wijzigingen moeten worden overgenomen. 

Niet voor alle files zijn er difference program, maar voor tekst files zijn ze wel te koop. Ook als er 

wel een difference program is, is er niet voor alle typen files een merge program, en soms slechts 

een al dan niet interactive 2-way merge. 

Waarschuwing 

Niet altijd is merging toereikend. Daarom is het goed om te overleggen, als parallel-wijzigingen 

verenigd moeten worden. In het voorbeeld “Merge is onvoldoende” zouden Lagus en Cunie 

Pagina: 102 / 230 

Interactieve 2-way merge 

Cunie weet dat ze Jos niet verwijderd heeft, dus ze zal alleen Lenie toevoegen, Klaas 

wijzigen en Rein verwijderen uit de versie van Lagus




kunnen afspreken dat Lagus zijn aanpassing uitbreidt als hij het laatste zijn envelope overdraagt 

maar dat Cunie het doet als zij het laatste is. In het voorbeeld zijn de wijzigingen geconcentreerd in 

een tabel in een file. Maar je kunt ook langs elkaar heen werken in verschillende files, of in 

verschillende delen van één enkele file, dan is het merge programma helemaal ontoereikend, om 

een conflict te herkennen. Een klein testje toonde aan dat ook mijn c compiler hier geen warning 

gaf. Dus mogelijk zou zo'n onvolkomenheid zeer laat en moeizaam ontdekt kunnen worden. 

Voorbeelden die mis kunnen gaan: 

● de classes C1, C2, C3 erven van class C. Cunie breidt C uit met een functie, en controleert in 

C1, C2 en C3 of deze functie moet worden overschreven, en in C3 is dat inderdaad het 

geval. Ondertussen maakt Lagus de class C4 die ook erft van C. In C4 is de controle van 

Cunie achterwege gebleven. Stel nu dat veel later ontdekt wordt dat de functie in C4 ook 

overschreven had moeten worden, dan moeten de registraties in de repository kunnen tonen 

dat de oorzaak van de fout hoogst waarschijnlijk een parallel update is. Als je erop 

doorzoekt vindt je misschien de class C5 van Lepus, die in diezelfde tijd is gemaakt. Als je 

dan C5 en C4 naast elkaar legt dan blijkt bijvoorbeeld, dat het assignment “C5 object = C4 

object “ niet triviaal is maar expliciet moet worden geprogrammeerd. Lagus en Lepus 

hadden slechts C1, C2, C3 hierop gecontroleerd. 

Als je wijzigt op één plaats in de source code, dan controleer je misschien wel tien plaatsen 

op neveneffecten, maar het kan je ontgaan dat er een elfde plaats ontstaat, of dat één van de 

tien gewijzigd wordt. 

● Cunie lost probleem P1 op en Lagus P2. Beide problemen vereisen dezelfde wijziging in 

functie F. Bijvoorbeeld: er moet een teller T verhoogd worden. Cunie plaatst aan het begin 

van de functie het statement T= T+1, en Lagus plaatst aan het eind van de functie het 

statement T = 1 + T (of misschien wel T++). Na merge zijn beide statements 

geïmplementeerd en wordt de teller onbedoeld twee maal verhoogd. 

● Cunie implementeert het raadplegen van een variabele of de aanroep van een procedure die 

door Lagus verwijderd wordt. 

● In het Darcs manual hoofdstuk “Theory of changes” worden wijzigingen integraal op de 

folder-tree beschouwd en wordt aandacht besteed aan replacements zoals naamswijzigingen 

van bijvoorbeeld variabelen of procedures. Met het simpele merge programma op versions, 

Pagina: 103 / 230 

Merge is onvoldoende




soms gecombineerd met een commander-achtig programma voor de wijzigingen op de 

folder-tree ben je soms (of misschien wel vaak) niet rigoureus genoeg. Bijvoorbeeld: de één 

verplaatst een procedure van file1 naar file2, terwijl de ander er een wijziging in aanbrengt. 

"Darcs" (http://darcs.net/) 

Conclusie: merge is slechts goed, voor een deel van de problemen met parallel updates. Maar voor 

versie één van Climbexion zullen we het er maar mee doen. 

Incidenten met parallel oplossen zal ik in de rest van het verhaal een “Lagus & Cunie” noemen. 

Waarom Lagus en Cunie? Ik heb mij laten vertellen dat die een doorsnee gehuwd stel 

representeren. 

Merge in Climbexion 

In Climbexion wordt een merge programma gebruikt op versions van dezelfde kin, die behoren tot 

hetzelfde file-type. 

Als we een merge uitvoeren om in de eigen team-drawer wijzigingen over te nemen van een file uit 

een andere drawer, bijvoorbeeld alle wijzigingen vanaf snapshot A tot en met snapshot B in de 

andere drawer, dan noemen we: 

1. de version van het snapshot A: original 

2. de tip uit de eigen drawer: base 

3. de version uit snapshot B: neighbor. 

De wijzigingen die nodig zouden zijn om van de original version de base version te maken zijn de 

te behouden wijzigingen, ofwel de “keep”. De wijzigingen om van de original version de neighbor 

te maken noemen we de “update”. 

Wanneer een envelope implemented is, en daarna wordt besloten om de wijziging niet door te laten 

gaan, dan zijn er voor een betrokken file twee mogelijkheden: 

● de labored version uit de envelope is nog steeds een tip: dan maken we zijn directe 

voorganger tot “labored” in de undo envelope, en de tip wordt “base”. 

● De version heeft opvolgers: Nu nemen we de version zelf als original, zijn voorganger (de 

base version uit de envelope) wordt de neighbor, en de tip van de file wordt de base. De 

wijzigingen op original om zijn voorganger te maken zijn de “update”, de wijzigingen op 

original om de tip te maken zijn de te behouden wijzigingen, de “keep”. 

Als we gisteren programma versie V2 hebben gemaakt in onze satellite, gebaseerd op V1, en we 

zien vandaag een nieuwe tip V3 in De team-drawer, waarop we de wijzigingen willen baseren, dan 

is voor de overgang op de nieuwe basis: 

● V1 de original 

● V3 de base 

● V2 de neighbor 

voor de uit te voeren merge. 

Het belang van een merge tool is vooral dat wijzigingen gemaakt in omgeving A overgenomen 

kunnen worden in omgeving B. Deze overnames willen we graag zo routinematig mogelijk 

uitvoeren, het liefst zo dat het tool dit autonoom doet, zonder interactie. 

Pagina: 104 / 230




Tenslotte 

● We hebben gezien dat het file-type kan wijzigen in de course van een file. Dan kun je geen 

merge gebruiken om wijzigingen in een versie met type FT1 over te nemen in een versie met 

type FT2. Dat wil natuurlijk niet zeggen, dat zo'n wijziging onmogelijk kan worden 

overgenomen, maar het kan niet routinematig, laat staan unattended. Zou je in plaats 

daarvan niet een andere file, dus een andere kin moeten gaan gebruiken? Waarschijnlijk is 

daar wel wat voor te zeggen, maar ik denk dat ik die beslissing aan de gebruiker laat, en niet 

aan Climbexion, of zijn bedenker. 

● Veel document editors bieden faciliteiten voor het opslaan van meerdere versies, in één 

document, om versies te integreren (merge) in een resultaat versie, om progressie te tonen 

met een difference analyse en dergelijke. De integratie van deze faciliteiten met Climbexion 

zal zeker niet onmiddellijk plaatsvinden, en misschien wel nooit. Eigenlijk zou je het liefst 

een versie van zo'n tool hebben zonder ingebouwde merge, maar met een drieweg merge 

tool meegeleverd. Dit weer typisch een voorbeeld van een revision control systeem dat 

eisen stelt aan een tool dat voor development wordt gebruikt. 

● Voor veel documenten, maar ook voor spreadsheets, en vector en object gebaseerde plaatjes 

(diagrammen), is er een syntaxis gedefinieerd zodat er ook een gewone tekst opslag 

mogelijk is (bijvoorbeeld TeX, XML, RTF, comma separated files). In principe zou een 

normaal merge programma hierop losgelaten mogen worden. Een voorwaarde is 

waarschijnlijk dat degene die de merge uitvoert de tekst file zou moeten kunnen lezen en 

verbeteren, bijvoorbeeld om conflicten op te lossen. Een merge zou gevolgd kunnen worden 

door uitvoering van een static analyzer: een check programma op syntaxis en 

onwaarschijnlijke constructie, die het conflicten lijstje, indien nodig, uitbreidt. 

Software-ontwikkel-teams met een werkwijze die afhankelijk is van merge zouden hun 

ontwikkel tools zo moeten kiezen dat de source files die gemaakt worden kunnen worden 

verenigd met merge. Ze kunnen verbeterd worden met een tekst editor in een IDE, liefst 

natuurlijk zo dat ze het effect van de wijziging meteen WYSIWYG kunnen bekijken in een 

window met het document, de spreadsheet, of het diagram. Je hebt niet alleen de juiste tools 

nodig maar ook de juiste mensen die niet alleen maar wysiwyg kunnen werken. Dat eist wel 

enige opleiding denk ik. Integratie tot een binary kan plaatsvinden met behulp van een make 

tool en een compiler. Deze geïntegreerde files zijn er voor de lezers en gebruikers van de 

informatie. De makers van de informatie wijzigen bijvoorbeeld direct op de source files, of 

ze zien de tekst van de source files en het resultaat wysiwyg, en wijzigen op één van beide 

presentaties, en zien de wijziging ook in de andere. Al met al lijkt het een behoorlijke 

inspanning te kosten om te komen tot een repository voor alle source files, als ze allen 

parallelle ontwikkelingen moeten kunnen doormaken die later met een merge tool verenigd 

moeten worden. Voorlopig is er ook de oplossing dat software wordt toegewezen aan kleine 

groepjes personen, die parallel ontwikkelen vermijden, als het gaat om binaire source 

documenten voor analyse design en development. 

● Waarschijnlijk is de afhankelijkheid van een merge programma voor een repository een 

reden dat men terughoudend is met de introductie van case-tools, immers een adequaat 3weg 

merge tool ontbreekt meestal. Een andere reden kan zijn dat men terugdeinst voor de 

derived files die met case-tools gegenereerd worden, en die mogelijk ook hun plaats 

verdienen in de repository. 

Pagina: 105 / 230




2.4.2 Synchronisatie 

Soorten 

● De meest simpele soort synchronisatie maakt de tip van een drawer exact gelijk aan een 

snapshot van een ander. Ook een deel van een drawer, bijvoorbeeld een package kan exact 

gelijk worden gemaakt aan die van een ander. Dit noemen we exact copy. Exact copy wordt 

uitgevoerd op alle typen course-items. (Name, folder reference, version). Envelope 

references worden niet gekopieerd, want ze worden niet gerekend tot de course van een 

element, maar tot een attribute van het event dat de course uitbreidt. Alleen een wijziging 

breidt een course uit. De course van een ongewijzigd element blijft ongewijzigd. Import en 

export limitations zijn mogelijk, maar niet altijd noodzakelijk. 

● Dan is er synchronisatie die mogelijk periodiek plaatsvindt. Uit drawer A wordt gekopieerd 

naar B. Wijzigingen die in B zijn aangebracht (neighbor) sinds de vorige synchronisatie 

(original) mogen niet vervangen worden, maar moeten worden worden gemengd (merge) 

met overeenkomstige nieuw gewijzigde elements in A (base). Het resultaat (labored) komt 

in de working-tree, en kan met commit worden geplaatst op de tip. Als het overeenkomstige 

element niet in A gewijzigd is hoeft er uiteraard niet gekopieerd of gemengd te worden. Ook 

dit kan plaatsvinden over de hele drawer of over een deel ervan. Naar keuze kan merging 

wel of niet unattended (automatisch, zonder toezicht) plaatsvinden. Een unattended merge 

kan incidenten loggen, als er conflicten optreden, of als er files betrokken zijn waarvoor 

geen merge program bestaat. Als er conflicten of problemen opgelost moeten worden moet 

alsnog iemand met een editor de integratie van de wijziging verzorgen, of bij een naam of 

folder conflict beslissen welke naam of referentie gebruikt moet worden. Kopiëren met 

unattended merge noemen we merge copy. Zonder unattended merge synchroniseren 

betekent dat gewijzigde elements in B niet automatisch worden vervangen, als elements ook 

in A gewijzigd zijn. De merge moet handmatig (interactief) gebeuren. Deze methode 

noemen we careful copy. Een lijstje dat aangeeft welke elements een interactieve merge 

moeten ondergaan of waar een beslissing moet worden genomen over een naam conflict 

dient dan als “to do” lijstje. Vaak worden import limitations gebruikt om files die niet met 

merge zijn samen te stellen, uit te sluiten. 

Climbexion software moet het volgende garanderen bij deze copy methoden: 

Als een course item de tip niet wezenlijk wijzigt (version, name of folder reference blijven 

hetzelfde), dan vindt het event dat de course zou uitbreiden niet plaats. Er wordt geen event 

toegevoegd. 

Synchronisatie is een “pull”action: in de “eigen” drawer synchroniseer je elements met een andere 

drawer. Er wordt geen envelope gebruikt voor een dergelijke actie, maar als import of export 

drawers gesynchroniseerd worden met een nieuwe release dan dient de envelope als certificaat. De 

envelope is dan eigenlijk een externe representatie van de changeset, en garandeert dat de nieuwe 

release door de build manager in de drawer is geplaatst, want de envelope bevat zijn elektronische 

handtekening. 

Pagina: 106 / 230




2.4.3 Synchronisaties tussen satellite en working-tree 

Nieuwe elements 

In een working-tree kunnen files voorkomen die niet in het revision control system zijn 

geregistreerd. Bijvoorbeeld build results voor unit tests, of test results, adhoc programmatuur, of 

nieuwe folders en programma's. In version control systems zorgt een configuratie file ervoor dat 

nieuwe files in hun totaliteit, als groep, geregistreerd kunnen worden in de satellite: de configuratie 

file fungeert dan als poortwachter, die sommige files niet toelaat. We veronderstellen dat dergelijke 

configuratie files eenvoudig door één man in een team zijn te maken, en bij te houden. In wezen 

betreft dit import limitations op een satellite, voor nieuwe elements die overgedragen moeten 

worden vanuit de working-tree. Ook de entity types en file-types van de nieuwe files en folders 

moeten of worden herkend met behulp van de configuratie files, of alsnog met de hand worden 

toegekend. 

Een nieuwe file betekent: 

● Er wordt een kin voor vastgelegd in een pool. 

● Er wordt een element met course voor gemaakt in de satellite. 

● Een version wordt geplaatst in een pool. 

Climbexion werkt met privé satellites, dus is er mogelijk nauwelijks een argument te vinden om 

files in een working-tree niet ook op te slaan in de satellite: hun bestaan is immers een historisch 

feit, en je hoeft zo'n file immers niet per se over te dragen naar de center-drawer. 

De meeste files moeten worden worden geregistreerd als gewone file, maar sommigen zijn otherfocused 

files. In de configuratie file moet mogelijk ook aangegeven worden welke files in 

aanmerking komen om als other-focused file te worden geregistreerd. 

Behalve files kunnen ook nieuwe folders en packages voorkomen in de working-tree. Nieuwe 

folders registreren, door ze te creëren in de working-tree en ze daarna met de registratie opdracht in 

de satellite en de pools te registreren is net zo simpel als files registreren. Gewone folders moeten 

wel zijn te onderscheiden van packages (via de configuratie files of door middel van manuele 

opgave of met behulp van van metadata). 

Een elders bestaand package moet kunnen worden geregistreerd als een reference, om daarna de 

satellite en de working-tree te synchroniseren vanuit een andere drawer. 

Een nieuw package registreren, en er de pools voor opzetten moet ook mogelijk zijn. De inhoud van 

het package moet daarna toch vanuit de working-tree zijn te registreren. 

Registreren vanuit de working-tree gebeurt in veel revision control systemen met een “add” 

opdracht. Deze opdracht kan parameterloos zijn, of hij kan een expressie bevatten die de registratie 

beperkt tot de elements die met de expressie geduid worden. Eventueel impliceert het registreren 

ook het overnemen van name, folder reference, version en dergelijke in de drawer, dus “add” 

impliceert “commit” . 

Een nieuw element maken voor working-tree en satellite samen. 

Dit is mijn favoriete methode. Een tool gebruikt een template om de folder, of de file te maken in de 

working-tree en registreert het element meteen in satellite en kin pool. Een configuratie file lijkt niet 

nodig. Een mogelijke variant: Het tool werkt onafhankelijk van Climbexion, de “add” opdracht 

Pagina: 107 / 230




wordt gebruikt voor opname in de drawer. 

Geregistreerde elements bijwerken vanuit de working-tree. 

Hiervoor gebruikt men over het algemeen de “commit” opdracht. Naam en folder reference 

wijzigingen kunnen niet zonder meer met commit worden overgedragen, maar eisen speciale 

opdrachten. Ook het beëindigen van een course eist mogelijk specifieke opdrachten. 

Opmerking: 

Als het file system van de working-tree toestaat dat kin identifiers, element-types en dergelijke als 

metadata worden opgeslagen bij de elements, zou met één enkele opdracht de satellite kunnen 

worden bijgewerkt vanuit de working-tree. 

Voorbeelden: 

● bij nieuwe elements zou de top folder van een package herkend kunnen worden aan de 

metadata. 

● Bij bestaande elements zou beëindiging, verplaatsing, en naamsverandering kunnen worden 

herkend, want de kin identifier is bekend. 

● Een nieuwe version wordt herkend aan de version identifier, i.p.v. De “date last modified”. 

De working-tree bijwerken vanuit de satellite. 

Exact copy maakt de working-tree gelijk aan de tip van de satellite. In de configuratie file kan staan 

welke ongeregistreerde files en folders kunnen vervallen en welke je wilt behouden. 

Merge copy plaatst het resultaat van een merge in de working-tree. De merge vindt plaatst met 

original en neighbor in een drawer, en base in tip van de satellite. Er is “commit” nodig om de 

satellite up-to-date te maken. Eventueel kunnen merge conflicten interactief, of naderhand met een 

editor worden verholpen, voordat “commit” wordt uitgevoerd. 

Pagina: 108 / 230




2.4.4 Het werken met team-drawer, transfer-drawer en satellite. 

Course Element E1 Envelope Element E1 

version Type Timestamp Seqnr version Type 

Wa Base T 1 Wa Base 

Wb Labored T+1 2 Wc Labored 

Wc Labored T+2 

Om met een schone lei te beginnen doen we een exact copy over de hele inhoud van de tip-tag van 

de center-drawer, naar de satellite. De tip van de satellite wordt met een tag tot “base” verklaart, 

want hij vormt de basis van nieuwe wijzigingen. Als de base de start van een nieuw probleem 

markeert is het zelfs een “problem base”. Dan wordt de working-tree gelijk gemaakt met de tip van 

de satellite: exact copy. We gaan nu wijzigingen aanbrengen in de working-tree, die we met 

“commit” vastleggen in de satellite. 

Als we wijzigingen willen behouden dan beginnen we met “commit” van alle betreffende files. Dan 

plegen we “exact copy” vanaf de tip-tag van het center. Deze copy wordt de nieuwe tip van de 

satellite, en voorzien van een “base” tag. Daarna vindt de merge plaats met de vorige base als 

original en de zojuist vervangen tip als neighbor. De nieuwe versies komen in de working-tree. 

“commit” plaatst ze terug in de satellite. 

Met de opdracht “commit” worden wijzigingen vanuit de working-tree overgedragen naar de 

satellite, maar vaak tegelijk ook ook naar een envelope. In een envelope komen “base” / “labored” 

paren van de elements die gewijzigd zijn. Het meest recente “labored” version vervangt een 

eventueel eerder geregistreerde version in de envelope. Voor de envelope geldt: alleen het resultaat 

telt, dus niet de historie. Met een expliciete opdracht kunnen een oude base, en het labored snapshot 

op die base verwijderd worden uit de envelope. Dit moet met een aparte opdracht worden gedaan, 

want, zoals later blijkt, het kan zin hebben om dezelfde wijziging te baseren op meer dan één base. 

Pagina: 109 / 230 

Synchronize, Edit, en Commit 

Course Element E1 Envelope Element E1 

version Type Timestamp Seqnr version Type 

Wa Base T 1 Wa Base 

Wb Labored T+1 2 Wc Labored 

Wc Labored T+2 3 Wd Base 

Wd Base T+3 4 We Labored 1 ) 

We Labored 1 ) T+4 

Synchronize again, Merge, Commit 

1 ) In dit geval zullen we de satellite niet vervuilen met de triviale informatie dat Wa de original, en Wc de 

neighbor is van een merge die leidt tot We.




De envelope variant 

Bij het implementeren van wijzigingen kan het voorkomen dat iemand gebruik maakt van 

Pagina: 110 / 230 

Envelope gebaseerd op tip-tag van het center en tip van de transfer-drawer 

Geselecteerde implementation data




beschikbare of van adhoc instrumentatie. Eerst ter analyse, later om het effect van de wijziging te 

demonstreren. Hierbij kunnen working-tree files buiten de envelope gewijzigd zijn. Bijvoorbeeld 

om enige logging te activeren, wijzigt men een gedefinieerde constante in een programma. 

De variant begint als altijd met een exact copy van de tip-tag van de team-drawer. Afhankelijk van 

de duur van analyse, software wijzigingen en testen kan besloten worden om tussentijds met merge 

copy een nieuwe base te implementeren. 

Tenslotte volgt een fase waarin de uiteindelijke wijzigingen hun vorm krijgen. Als de envelope 

klaar is worden de component test en de overdrachts-test (een kleine regressie test) uitgevoerd. Dit 

is een test met menselijke waarneming en handmatige handelingen. In sommige projects wordt ook 

een statische analyse uitgevoerd met het QAC tool. 

In deze één na laatste laatste fase mogen er in files buiten de envelope geen verschillen meer zijn 

met de tip-tag van de team-drawer, want dat wordt vereist voor de component en regressie tests. Om 

dit te waarborgen kan gebruik worden gemaakt van een synchronisatie die zorgt dat alles buiten de 

envelope een exacte kopie wordt van de tip-tag van de team-drawer, en alles binnen de envelope 

met merging wordt gebaseerd op de tip-tag. Deze methode is de “envelope variant of careful or 

merge copy”. Careful copy is met name van belang als er in de elementen in de envelope gewijzigd 

is ten behoeve van ad hoc logging, want deze wijzigingen mogen niet overgedragen worden naar de 

team-drawer. Met een interactieve merge kun je deze wijzigingen teniet doen. Waarom de tip-tag 

van de team-drawer en niet de tip van de transfer drawer? Wel, voor de tip-tag geldt dat er een 

kwaliteit waarborg is afgegeven door de build manager. Dit maakt het iets waarschijnlijker dat test 

of build problemen veroorzaakt worden door eigen fouten. 

Als laatste fase kan synchronisatie worden herhaald met de verwachte tip (in plaats van de tip-tag 

van de team-drawer): dit is de tip in de transfer-drawer. Deze tip wordt een snapshot in de teamdrawer 

als alle envelopes, die zijn overgedragen sinds de tip-tag ontstond, worden overgedragen aan 

de team-drawer. Als voorgaande, reeds overgedragen envelopes (mogelijk van anderen) één of meer 

elements bevatten die ook in de eigen envelope voorkomen, dan is er, door deze laatste merge copy, 

voor sommige elements een nieuwe base ontstaan, en een door merge verkregen nieuwe labored 

version. Deze worden in de envelope geplaatst (dus de versions die gebaseerd zijn op de center tiptag 

blijven ook in de envelope staan). De programmeur controleert of het compileren goed verloopt 

(en in sommige projects of QAC geen warnings geeft), en zo ja dan kan de envelope worden 

overgedragen. In deze laatste fase blijven de tests achterwege, maar er wordt wel een build 

uitgevoerd. 

Dit waren de regels in de meeste fasen in de meeste projects van NXP. 

Als de wijzigingen van een element gebaseerd zijn op versions die geen tip zijn in de transferdrawer 

of de team-drawer, dan wordt de envelope geweigerd als je hem wilt overdragen naar de 

betreffende drawer. Tenminste één van de paren base/labored van een element moet de juiste base 

hebben. Nadat een envelope met inhoud is overgedragen naar de transfer-drawer, vinden er ook van 

daar uit nog acceptatie tests plaats, voordat de overdracht naar de center-drawer wordt gerealiseerd. 

Dit hoort een formaliteit te zijn, maar soms worden fouten geconstateerd. Dan is het zaak om een 

envelope als schuldige aan te wijzen (soms meerdere). Als de build manager besluit om de foute 

envelopes niet mee te nemen dan kan hij de tip-tag van de team-drawer gebruiken om opnieuw een 

basis te creëren in de transfer-drawer, en daarop de niet geweigerde envelopes opnieuw aan te 

brengen, eventueel met enige extra base / labored paren. Ook kan de build manager besluiten om de 

Pagina: 111 / 230




schuldige envelope tegen te boeken, met een “undo envelope” op de tip van de transfer-drawer. 

In de laatste fasen van een project wordt vaak de transfer-drawer overgeslagen. Envelopes worden 

dan na een aangepaste overdrachts-test onmiddellijk in de team-drawer geplaatst. Daarna wordt er 

een external envelope gemaakt, en verstuurd. 

Overdrachten worden gerekend tot de “push” methoden: vanuit de “eigen” drawer (de satellite) 

wordt gepusht in de andere drawer (de transfer-drawer). 

Normaal streeft men er naar om een wijziging binnen een dag te realiseren, soms lukt dit niet. 

Sommige wijzigingen zijn niet simpel te splitsen in hapklare brokken van één dag, soms heeft men 

pech met hardware, of komt er een hogere prioriteit wijziging tussendoor. Vaak echter kan iemand 

meerdere wijzigingen op één dag realiseren. 

Soms realiseer je meerdere envelopes en pleegt dan de vereiste overdracht tests en builds op het 

geheel. 

Routine werk met Climbexion: 

1. Full snapshot copy 

2. Difference snapshot copy: base for merge. 

3. Difference snapshot copy: base for envelope variant of merge. 

4. Difference snapshot copy: base for envelope variant of merge. 

5. Transfer copy: envelope content 

6. Transfer copy: envelope content 

opmerking: 

Een M /EM boog representeert original en neighbor, de pijlpunt representeert de base van de merge. 

Pagina: 112 / 230 

Routine werk met Climbexion




Enige kanttekeningen. 

● Door de architectuur van de layer waaraan ik werkte, waren er sommige files die zeer 

frequent gewijzigd werden. Deze files werden op één dag soms door meerdere mensen 

gewijzigd en zo ontstond de behoefte om meerdere alternatieve base / edit paren aan te 

bieden in een envelope. De geschetste werkwijze beperkt het aantal paren tot twee. Gegeven 

de eis om bepaalde builds uit te voeren voor elk snapshot waarop de wijzigingen zijn 

gebaseerd is het ondoenlijk om als derde of vierde in een rij van envelopes een alternatief 

maken voor elke mogelijke situatie die zich kan voordoen, als voorgaande envelopes worden 

geweigerd. (Zie ook 2.8.3) 

● Mijns inziens kan de overdracht van transfer-drawer naar team-drawer zo geautomatiseerd 

worden, dat ze meermalen per dag uitgevoerd kan worden. Er kunnen dan meerdere tags 

per dag gemaakt worden. Dit zou de kans op update op update van nog niet 

geïmplementeerde envelopes kunnen verminderen. 

● De deel van oplossing is misschien om te zorgen dat de individuele checks afdoende zijn, 

zodat transfers rechtstreeks kunnen worden aangebracht in de center-drawer, en ieder altijd 

de tip van de center-drawer gebruikt als base. De build manager zorgt éénmaal per dag –, 

of extra tussendoor na klachten –, voor builds en regressie tests. Als een fout gevonden 

wordt, dan wordt een nieuw probleem geregistreerd, of een oud probleem heropend. Als de 

situatie urgent is dan wordt de fout onmiddellijk opgelost, samen met de boosdoener wiens 

envelope de fout introduceerde. Dit kan eventueel door een “undo” van de betreffende 

envelope, maar liefst door de fout te herstellen. In deze situatie komen other-focused files 

zoals build results, en test results van de regressie tests goed tot hun recht. Er hoeft niets 

voor te worden geblokkeerd. 

● In een working-tree kunnen twee soorten wijzigingen voorkomen: wijzigingen binnen een 

envelope, en wijzigingen erbuiten. Wijzigingen binnen een envelope moeten worden 

zichtbaar gemaakt, voor andere gebruikers van de center-drawer. Voor een envelope in het 

preparing stadium zou je een “commit” commando moeten gebruiken om hem zichtbaar te 

maken, zodra de wijziging zich aftekent. 

● Satellites maken het mogelijk om een gewijzigde version onmiddellijk vast te leggen in de 

satellite. Er zijn dan files die wel, en files die niet worden bijgehouden in een envelope. Er 

kunnen commits plaatsvinden van versions met adhoc logging, en tenslotte van versions 

zonder deze logging. Op deze manier is een satellite een persoonlijke log van van de eigen 

activiteiten. 

● Ideaal zou zijn als één persoon één satellite heeft. Maar het is waarschijnlijk efficiënter als 

een satelliet onlosmakelijk bij een center hoort. Werkt iemand voor twee centers dan zijn er 

in ieder geval twee satellites. Werkt iemand binnen een center-drawer aan twee 

onafhankelijke wijzigingen tegelijk, dan zijn er twee satellites nodig. Het meest 

overzichtelijk is waarschijnlijk het gebruik om per wijziging één satellite te maken. 

● Hoe één en ander in zijn werk gaat bij de moderne gedistribueerde version control systems: 

zie “DVCS Round-Up: One System to Rule Them All?” van Robert Fendt 

(http://ldn.linuxfoundation.org/article/dvcs-round-one-system-rule-them-all-part-1) 

● Op het internet vond ik vergelijkingen van revision control systems, waarin gemeld werd dat 

sommigen de wijzigingen opslaan die leiden tot een nieuwe version. De wijzigingen voor 

adhoc logging hoeven niet te worden meegenomen in de envelope, maar de echte 

wijzigingen wel. Hiervoor werd de term “interactive commit” gebruikt. In de eerste release 

van Climbexion wordt deze methode niet geïmplementeerd: de resulterende versions worden 

Pagina: 113 / 230




vermeld in de envelope, niet de delta ten opzichte van de base. Een systeem met dergelijke 

faciliteiten: “Darcs" (http://darcs.net/), "Fossil", (http://www.fossil-scm.org/). In plaats van 

“Interactive commit” is er in Climbexion: “careful copy” en die gaat aan de commit 

vooraf. 

● We hebben te maken met een viertal tests. De eerste drie worden uitgevoerd door een 

programmeur. De programmeur is aanwezig op de werkplek en kan geluid en beeld 

controleren, de afstandsbediening gebruiken, een dvd in een speler stoppen, apparaten 

aansluiten of pluggen eruit trekken. 

Adhoc tests. Eerst laten ze zien wat het probleem is daarna dat de wijziging werkt. 

Component tests laten zien dat de gewijzigde components zich gedragen zoals verwacht. 

(sommige component tests hoeven trouwens niet te draaien op een TV, maar kunnen 

uitgevoerd worden op een PC) 

De transfer test, toont aan dat de layer nog steeds voor dagelijks gebruik geschikt is. 

De acceptatie test wordt uitgevoerd op een vooraf geprepareerde werkplek zonder dat er 

iemand aanwezig is. Het is een uitgebreide regressie test, die door de build manager 

wordt gebruikt. 

De adhoc tests worden meestal uitgevoerd met behulp van de afstandsbediening of middels 

een interactieve sessie. Met uitzondering van de adhoc tests volgen de tests een script, dat in 

samenwerking met een tester is gemaakt. Component test scripts worden gemaakt door de 

programmeur, en daarna beoordeeld door een tester. De inhoud van transfer tests en de 

acceptatie test zijn volledig de verantwoordelijkheid van de testers. 

Omdat ze de verantwoordelijkheid waren van de testers, liepen de tests soms achter bij de 

software. Er werd dan ook wel eens op gemopperd. Dat was niet altijd terecht. Ik heb wel 

eens gemopperd op de test en daarna een showstopper overgedragen. Met de test was niets 

mis, maar met mijn wijziging in de software wel. 

● Er zijn nogal wat builds betrokken bij dit alles. Voor MIPS software is er een debug mode en 

een optimize mode mogelijk voor een build. Voor TriMedia software wordt gebruik gemaakt 

van een optimize mode, wel of niet met logging options, en een “assert mode “. 

Probleem reproductie: product en/of layer build in optimize mode of debug mode. 

Adhoc tests: product en/of layer build in debug mode. 

Component tests: build van een eigen test harness of misschien een layer build, in debug 

mode 

Transfer test: layer build, in debug mode 

Pre transfer build: product en/of layer build, in optimize mode 

Daily builds door build manager: product en layer builds in debug en optimize mode. 

● Tijdbesteding van een ontwikkelaar (in willekeurige volgorde): 

Synchroniseren en kopiëren (koffie drinken). 

Het voorbereiden van een test werkplek. (soms moet je zoeken naar spullen) 

Testen 

Soms moet je wachten tot een werkplek of een apparaat beschikbaar komt (koffie 

drinken). 

Builds (koffie drinken) 

Analyseren en programmeren 

Pagina: 114 / 230




2.4.5 Een geabonneerd package inlijven 

Geabonneerd package overnemen. 

Ongeveer worst case scenario, omdat er wijzigingen ontwikkeld worden, en er external envelopes 

ontstaan. Die hadden er eigenlijk al moeten zijn 

1. Copy exact: base 

2. Copy exact: differences of package only: source for envelope 5. 

3. External envelope applied to satellite, source for envelope 6. 

4. External envelope applied to satellite, source for envelope 7. 

5. Envelope originated from differences between 1 and 2. 

6. Envelope originated from external envelope 3. 

7. Envelope originated from external envelope 4. 

8. Envelope on own packages source for external envelope 10. 

9. Envelope for own packages source for external envelope 11. 

10. External envelope originated from envelope 8 

Pagina: 115 / 230 

Geabonneerd package overnemen.




11. External envelope originated from envelope 9 

12. New base for envelopes 8 to11. 

13. Additional base for envelopes 8 to 11. 

14. Transfer as a whole 

15. Transfer as a whole 

16. External envelopes are finished in baseline constellation for final base / labored pairs 

Als een integrator een nieuwe baseline van een geabonneerd package implementeert dan wordt de 

baseline exact overgenomen. Eventuele patches raak je kwijt, eventuele nieuwe patches kunnen 

daarna worden aangebracht. Dit betekent: 

● De integrator synchroniseert zijn satellite met het center, om een base te maken. 

● De tip van de satellite, de primaire envelope, en de working-tree worden bijgewerkt door 

een query die een baseline van het package uit de import drawer kopieert. 

● Er vinden tests plaats, mogelijk worden baseline supplements aangebracht in de satellite en 

één op één gekopieerd in eigen envelopes. De eigen packages worden indien nodig 

gewijzigd, dat kan soms betekenen dat deze wijzigingen ook als baseline supplements 

worden uitgegeven. De aanpassingen van eigen packages komen in separate envelopes . 

Alle envelopes worden gerelateerd aan elkaar en aan de primaire envelope, en er wordt een 

onderlinge volgorde vastgesteld: de comrade volgorde. Deze volgorde realiseert de partiële 

ordening die ontstaat als de labored file version in de ene envelope een base version is in de 

andere. 

● De wijzigingen op de eigen packages moeten mogelijk tussentijds en tenslotte opnieuw 

worden gebaseerd op de tip-tag van het center, waarna de vereiste builds en tests 

plaatsvinden. Daarna worden ze nog eens gebaseerd op de tip van de transfer-drawer, 

waarna de vereiste builds plaatsvinden. 

● Het geheel wordt overgedragen. 

2.4.6 Het overnemen (adopt) van envelopes uit een sister-project 

Het principe is simpel: de eigen envelope bevat een referentie naar de over te nemen andere 

envelope. Voor elke file in de andere envelope geldt: 

● De base van de ander wordt het original in de eigen. 

● Labored in de ander wordt de neighbor in de eigen. 

Immers diff(base ander,labored ander) representeert de wijziging die is teweeg gebracht door de 

andere envelope en diff(base ander, base eigen) representeert datgene dat behouden moet worden. 

Soms zijn er alternatieve base/labored paren bij een file. Dan geldt over het algemeen het paar dat 

geïmplementeerd is in de center-drawer. 

In principe kun je net zo veel envelopes opnemen in de query van de eigen envelope als je wenst. 

Op deze manier kan gesynchroniseerd worden, terwijl een aantal wijzigingen niet meegenomen 

worden. Als een file voorkomt in meerdere envelopes dan leidt dit tot de volgende lijst: 

base 

original 

neighbor 

labored (new base for next merge) 

Pagina: 116 / 230




original 

neighbor 

labored (new base for next merge) 

···· 

···· 

labored 

labored (edit conflict and wrong solution solving) 

Climbexion moet mogelijk zo gemaakt worden dat de volgorde van originals en neighbors in deze 

lijst overeenkomt met de volgorde van de changesets in het andere project. 

Deze mogelijkheid om meerdere envelopes over te nemen in één enkele wordt misschien niet 

meteen geïmplementeerd in Climbexion. Dus zal men dit moeten realiseren met comrades, en vindt 

er geen "indikking" plaats waarbij uiteindelijk alleen de laatste labored version wordt overgedragen 

naar transfer en team-drawer. 

Optimistisch als altijd heb ik slechts één “edit” versie opgenomen in deze lijst, maar er mogen er 

meerdere zijn. 

Flexibiliteit is vereist. Vaak zal er een mix zijn van overgenomen wijzigingen, en een keuze voor 

andere oplossingen. Bijvoorbeeld een wijziging die geïmplementeerd is gedurende een development 

activiteit: het streven bij zo'n wijziging is om de complexiteit van de software zo klein mogelijk te 

houden. Maar bij een wijziging laat in de verificatie fase is het streven primair om zo weinig 

mogelijk regressie te veroorzaken. Dit wordt bereikt door “defensive programming” en door de 

wijziging zo klein mogelijk te houden. Als een wijziging wordt overgenomen in een backbone 

project, dan kan de focus verschuiven omdat in een backbone project de nadruk ligt op het 

minimaliseren van de totale complexiteit, en reusability waar die bij de laatste fasen van het designin 

project ligt bij het minimaliseren van regressie en te wijzigen code. Ook het implementeren van 

een feature dat geselecteerd kan worden is met behulp van een configuratie file of andere vormen 

van diversity kan in een backbone project anders zijn dan in een design-in project. 

Pagina: 117 / 230 

Overnemen van een wijziging uit een ander project




In NXP wordt een systeem van problem tracking gebruikt waarin sibling relaties mogelijk zijn voor 

problem reports en change requests, en is er regelmatig overleg of problemen gevonden in het éne 

project moeten worden overgenomen als sibling in het andere. Ook bij Philips CE was men hierop 

zeer alert. 

Daarnaast is het nog mogelijk dat men oplossingen uit andere projects overneemt, zonder dat hierbij 

een envelope of een change request of een problem report in de andere drawer een rol speelt. Een 

original is dan mogelijk niet eenduidig aan te wijzen. Onder die omstandigheid is het waarschijnlijk 

niet correct om de file waaruit de oplossing wordt overgenomen, om die een neighbor te noemen. 

envelope copy 

1. Full snapshot copy 

2. Existing envelope supplies original and neighbor 

3. Apply merge 

4. Snapshot copy: some differences are additional base for envelope E 

5. Transfer copy: envelope E content 

6. Transfer copy: envelope E content 

2.4.7 Undo envelope 

Een envelope die erg op een adopt envelope lijkt is de undo envelope. Ook deze refereert naar een 

andere envelope, alleen de toewijzing van originals en neighbors is anders. 

● De labored versions in de gerefereerde envelope worden de originals in de eigen envelope 

● De base versions in de gerefereerde envelope worden de neighbors in de eigen envelope 

Pagina: 118 / 230 

envelope copy




2.4.8 synchroniseren van eigen packages met die van een sisterproject 

(adopt merge) 

File Original Base neighbor Action 

File1 File1.A File1.C File1.E merge 

File2 File2.C File2.C File2.E copy 

File3 File3.D File3.C File3.A merge 

Merge_copy package from Project Old to Project New 

Het betreft hier wijzigingen op de eigen packages. 

De integrator begint met twee snapshots (of baselines of tags) te kiezen in de andere drawer, één 

voor de originals, en één voor de neighbors. Dan vindt er een query plaats die niet erg simpel is. Het 

synchroniseren van name en folder reference wijzigingen, en synchroniseren als een element 

intussen slechts in één van de drawers voorkomt: mijns inziens is een algoritme hier niet toereikend, 

iemand moet een beslissing nemen, en Climbexion levert slechts een conflict lijstje. 

Zo gaat de integrator te werk.: 

● Creëer een envelope en refereer naar een merge work-item 

● kopieer de base van de center-drawer naar je satellite (exact copy) 

● Als baseline Tn-1 van het sister-project de vorige keer geen neighbor was of als import of 

export limitations sindsdien gewijzigd zijn: importeer het package met baseline Tn-1 in de 

betreffende merge-import drawer. Dit worden de originals 

● Importeer het package in de betreffende merge-import-drawer, met tag Tn. 

● Voer eventuele undo envelopes uit voor wijzigingen die niet overgenomen moeten worden. 

Dit doen we in de merge-import-drawer (via een merge-import satellite natuurlijk). 

● Merge: original tag Tn-1, neighbor is de tip van de merge-import drawer, base de tip van de 

team satellite. De merge vindt plaats in de team satellite. Eventueel edit (mergeables en 

Pagina: 119 / 230




unmergeables). Het resultaat komt in de tip van satellite en envelop. 

● build, test, improve, resynchronize, transfer. 

Undo envelopes kun je toepassen op de merge-import-drawer voordat je een merge uitvoert, of op 

de labored versions in de team-drawer satellite nadat de merge is uitgevoerd. In het laatste geval 

loop je het risico dat je eerst conflicten oplost tijdens merge, en daarna nog eens tijdens undo, voor 

conflicten die gerelateerd zijn aan de wijzigingen die je niet wilt hebben. Verder zijn er mogelijk 

wijzigingen gerealiseerd in beide subprojects, door envelopes te adopteren. Undo daarvan kan het 

beste plaatsvinden op de merge-import-drawer. Undo hiervan in een team-drawer satellite is 

ongewenst: daarin wil je de reeds gerealiseerde wijziging behouden. Ook zijn de wijzigingen in het 

sister project mogelijk iets anders geïmplementeerd dan in de team-drawer: merge en daarna al dan 

niet undo levert dan een chaos op. Conclusie: undo pas je toe op de merge-import-drawer. 

De afkomst relaties blijven behouden door de query (inclusief export-drawer en sister-project) op te 

nemen in de envelope, en door original en neighbor in de envelope op te nemen bij de betreffende 

files in de envelope. 

De volgende keer dat vanuit dezelfde drawer gesynchroniseerd wordt, kan de base voor de undo 

operaties het original worden: de synchronisatie is dan adjacent ten opzichte van de voorgaande 

synchronisatie. Als je voor het eerst synchroniseert vanuit een sister-project waaruit het package 

door kopiëren is ontstaan, dan is de synchronisatie adjacent op de kopieer actie. De eerste versions 

in de eigen courses zijn dan de originals. Synchronisaties hoeven niet per definitie adjacent ten 

opzichte van elkaar te zijn. Als je bij een synchronisatie een willekeurig snapshot opgeeft in de 

drawer vanwaaruit gesynchroniseerd wordt, dan worden de wijzigingen vanaf daar tot aan de tip 

overgenomen. Als je in plaats van de tip een snapshot opgeeft, dan worden de wijzigingen tussen 

beide snapshots overgenomen: het eerste snapshot definieert de originals, het tweede de neighbors. 

Pagina: 120 / 230 

Team-drawer na Transfer 

original en neighbor zijn primair geregistreerd in de envelope, en daardoor indirect in het event.




Om dit te automatisch goede synchronisatie aansluiting te realiseren moeten de synchronisaties die 

een package ondergaat worden opgeslagen. Hiervoor wordt de drawer merge-imports gebruikt, 

waarin de changesets voorkomen die de vorige keer gebruikt zijn. 

Zo'n synchronisatie vindt enkele malen plaats bij de start van een project, daarna worden 

wijzigingen overgenomen door de envelopes over te nemen. Soms wordt een backbone project op 

deze manier voorzien van de wijzigingen in een design-in project. 

Pagina: 121 / 230 

Envelope voor file1 en file2 

Adopt merge schema




2.4.9 Gemeenschappelijk beheerde packages. 

Het avs (audio video system): de besturingslaag (eigenlijk moet ik zeggen: de server) waarin de 

drivers huizen, bevat packages die worden bijgehouden door NXP en enkele door de klant, of een 

third party. 

● Bijvoorbeeld Horcom gebruikt een model van alle audio en video paden. Dit model is min 

of meer exclusief voor één enkel type televisie, maar een groot deel modelleert de structuur 

van de NXP chip. Het model van de av-stromen wordt gerealiseerd met Koala interfaces: 

waar een audio- en/of video- stroom loopt tussen hardware componenten, daar zit een 

Horcom interface paar tussen de driver besturings-componenten. De besturingscomponenten 

vormen op die manier een soort puzzelstukjes die nog in elkaar gezet moeten 

worden. Dat doe je door de ingang van een component te verbinden met een uitgang van een 

directe voorganger, en dat dan voor alle ingangen en uitgangen. De component waarin al die 

verbindingen liggen wordt zowel door de klant als door NXP bijgehouden, maar de 

eigenaar van het master project is eigenaar van deze integratie component. De component 

wordt als package uitgegeven door de eigenaar. 

● De diversity van dit package is gecentraliseerd in een package dat weliswaar bestaat uit cd 

files, en c files, maar dat wordt bijgehouden als een invulformulier, waarop voor elk item 

een waarde of een functie aanroep wordt ingevuld. Ook dit package is van de eigenaar van 

het master project, maar wordt ook voornamelijk door NXP teams bijgehouden. 

Een ander voorbeeld: 

● Een team in India en een team in Nederland werken beide aan hetzelfde package en hebben 

ieder een team-drawer met satellites. 

Er zijn meerlingen methoden denkbaar. 

Meerlingen zijn bijvoorbeeld te realiseren met een gemeenschappelijke team-drawer (commondrawer), 

waarin de teams hun wijzigingen mengen, waarna ieder synchroniseert (exact copy) met 

de tip van de common-drawer. 

● Een discipline zou kunnen zijn dat eerst de team-drawer up-to-date gebracht wordt met 

behulp van envelopes. De common-drawer heeft een transfer-drawer. Nadat de overdrachten 

van de team transfer-drawer naar de team-drawer klaar zijn, vindt een merge copy plaats van 

de team-drawer naar de transfer-drawer van de common-drawer (original: de tag in de teamdrawer 

direct na de vorige keer, neighbor: de tip van de team-drawer), en na acceptatie 

checks (builds en mogelijk tests) een overdracht naar de common-drawer. Dan vindt een 

exact copy plaats van common-drawer op team-drawer. Dan wordt de tag voor de originals 

van de volgende keer gemaakt. 

● Iedere envelope wordt na acceptatie in de team transfer-drawer aangebracht in de commondrawer, 

indien nodig worden daartoe base en labored paren toegevoegd aan de envelope. De 

team-drawer wordt bijgewerkt als clone van de common-drawer: alle changesets in het 

common-drawer worden ook changesets in de team-drawer. De team transfer-drawer wordt 

daarna met exact copy bijgewerkt. Voor envelopes betekent dit dat ze pendelen tussen 

common-drawer, en de team transfer-drawer en satellites die bediend worden door de 

common-drawer. 

● Variatie op de vorige werkwijzen: Eerst brengen alle teams hun wijzigingen aan op de 

common-drawer, daarna pas nemen met exact copy ze het resultaat over in hun eigen team- 

Pagina: 122 / 230




drawer. Er is nu een moment waarop alle team-drawers inhoudelijk dezelfde tip hebben. 

● Adjacency: wijzigingen voor de common-drawer hebben als original de vorige exact copy 

vanuit de common-drawer. 

Het geheel is natuurlijk gevoelig voor een probleem dat gelijktijdig wordt ontdekt en opgelost in 

meerdere teams, ieder op zijn eigen wijze, liefst ook nog met zijn eigen work-item, en zijn eigen 

beschrijving. Soms kun je dat niet voorkomen. Dan moet je de software herstellen, en proberen te 

vermijden dat je blijft zitten met een dubbele gemixte oplossing. 

2.4.10 Baseline samenstellen 

Zolang er een wekelijkse baseline werd uitgegeven, kregen wij (de software engineers) op 

donderdag te horen: “Vandaag en morgen niets inchecken, we gaan de baseline klaarmaken”. Er 

mochten dan nog slechts problemen worden ingecheckt, die noodzakelijk waren om de baseline te 

vervolmaken. 

Nu we drawers hebben kunnen we in één zo'n drawer en zijn satellites een baseline voorbereiden. In 

de team-drawer kan dan gewoon worden doorgegaan. Een consequentie is wel, dat je in de teamdrawer 

geen baselines van eigen packages kunt herkennen, de eigen baseline is namelijk niet altijd 

een snapshot in de eigen team-drawer, terwijl de baselines van geabonneerde packages er wel in 

terug te vinden zijn. Mogelijk worden ook de baseline reports alleen bijgehouden in de exportdrawer 

en niet in de team-drawer. 

In de officiële export-drawer wil je liefst geen tussenresultaten, maar uitsluitend baselines. Er is dus 

een extra center nodig: de baseline-drawer, waarin de wijzigingen worden opgebouwd tot de 

baseline klaar is. Daarna wordt met “exact copy” de export-drawer zelf bijgewerkt. De 

voorbereidende envelopes pendelen hier dus tussen baseline satellites en baseline-drawer. 

Het kan zijn, dat er vooraf afspraken zijn gemaakt over de inhoud van de baseline. Het snapshot van 

de tag van woensdag op donderdag kan wijzigingen bevatten waarvan afgesproken is dat die nog 

niet ingaan, ook kan dit snapshot wijzigingen missen die er nog met prioriteit in moeten komen. 

Niet alles is expliciet afgesproken, dan geldt in principe voor de wijzigingen: “hoe eerder hoe 

beter”, hoewel dit voor de ene wijziging meer geldt dan voor een andere. 

Het kan zijn dat wijzigingen niet genoeg zijn uitgekristalliseerd voor een baseline en daarom niet 

meegenomen worden: ze falen in de baseline tests. Ook kan het zijn dat wijzigingen falen in een 

baseline test en met prioriteit verbeterd worden, omdat het ernaar uitziet dat dat kan, en/of omdat 

het afgesproken is. 

Dank zij het gebruik van een baseline-drawer en zijn satellites is het geen probleem om met 

prioriteit dingen te doen, terwijl het gewone werk doorgaat. De envelopes die daarbij gebruikt 

worden kunnen deels gebruikt worden om daarna zonder prioriteit de team-drawer te verbeteren, 

op dezelfde manier als waarop wijzigingen uit een ander project worden overgenomen. 

Allereerst wordt met exact copy uit de team-drawer een base gemaakt in de baseline-drawer. 

Undo operaties gebruiken de envelope waarmee de wijziging is aangebracht in de team-drawer. De 

labored version uit de envelope is het original in de merge, de base version uit de envelope is de 

neighbor in de merge, en de tip version in de satellite van de export-drawer is de base van de merge. 

De volgorde der envelopes: de timestamps van de changesets, de meest recente eerst, denk ik, voor 

Pagina: 123 / 230




de zekerheid. 

Verbeter acties vinden verder plaats zoals in de team-drawer en zijn satellites. 

Tenslotte kan de baseline, met inachtneming van de export limitations gekopieerd worden naar 

export-drawers. 

2.4.11 Project dependencies. 

Binnen een product familie kennen we generaties, voor de software van NXP is een nieuw 

ontworpen chip een nieuwe generatie met een nieuw reference design / backbone project en daar 

van afgeleid de design-in projects. Wijzigingen in de design-in projects die algemeen bruikbaar zijn, 

zoals opgeloste fouten, worden ook aangebracht in het backbone project. Tussen het backbone 

project en de design-in projects wordt dan ook aardig wat gesynchroniseerd, en worden envelopes 

over genomen. 

Ook bij grote klanten wordt er vaak gewerkt met een fictief project: het backbone project. Ook hier 

is een nieuwe generatie (of een andere leverancier) van de elektronica vaak de reden om een nieuw 

backbone project te beginnen. Wijzigingen in design-in projects worden, als ze algemeen bruikbaar 

zijn, ook aangebracht in de backbone drawer. Nieuwe design-in projects worden gebaseerd op het 

backbone project. Van de software van het backbone project wordt geëist dat ze compileerbaar is 

voor alle layer builds, en alle product builds, en mogelijk dat delen ervan uitvoerbaar zijn op enkele 

testplekken. Synchronisatie en het overnemen van envelopes komen hier systematisch voor. 

Bij deze grote klanten participeert NXP niet alleen in de design-in projects, maar ook in het 

backbone project. In de eerste projects baseert NXP zijn packages op het eigen reference design 

project, later worden deze klanten bedient met packages die zijn gebaseerd uit het backbone project 

van de klant. 

Pagina: 124 / 230 

Baseline samenstellen met 2 ontwikkelaars en een tester




Een opmerking over het backbone / reference design project. 

Zolang design-in projects uitsluitend wijzigingen overnemen uit dit project, en wijzigingen ook 

invoeren in dit project, fungeert het project als een buffer tussen de diverse design-in projects. Er is 

een tendens om wijzigingen uit te wisselen tussen design-in projects, omdat het beleid voor 

wijzigingen tussen design-in projects overeenstemt. Na een start wordt dit beleid al gauw: 

“minimaliseer de wijziging”. Bij een backbone project is het beleid meer: “houdt de totale 

complexiteit zo laag mogelijk”. Het is immers steeds opnieuw een uitgangspunt voor andere 

projects. Dit verschil in beleid maakt dat er vaak manueel gewijzigd wordt, als wijzigingen van een 

design-in project worden doorgevoerd in het reference design. Soms als aanvulling op een merge, 

soms zonder merge. 

Een opmerking over adopts. Een nieuwe generatie chips begint met een design project. En daarmee 

een nieuwe reference design drawer. Deze begint met een import uit een voorgaand reference 

design. Kort na het begin van een design project, als de initiële integratie een werkend geheel heeft 

opgeleverd, worden de meer rigoureuze wijzigingen uitgevoerd zoals uitbreidingen, en redesign, 

nieuwe drivers voor nieuwe hardware enzovoort. Dit vindt voor het grootste deel plaats in het 

reference design / backbone project. Zolang herstructurering zich beperkt tot folder herindelingen, 

en hernoemen tot andere namen voor elements, kan Climbexion de samenhang met drawers van 

voorgaande projects vasthouden. Als hernoemen en herstructureren plaatsvindt op entiteiten binnen 

files, bijvoorbeeld procedures, die splitsen of verhuizen naar andere files, of waarvan de naam 

integraal gewijzigd wordt, dan heb je niets aan Climbexion: de samenhang met andere chip 

generaties is verloren gegaan. Na het design project beginnen de design-in projects, en daarmee de 

adopts. Binnen de chip generatie is adopt met “mechanische” middelen zoals een merge programma 

min of meer betrouwbaar, maar als je na de beginfase nog wijzigingen uit andere chip generaties wil 

overnemen dan moet je bedacht zijn op problemen die niet altijd met een merge programma zijn op 

te lossen. 

2.4.12 Informatie, werkelijkheid, gedistribueerd systeem 

De synchronisaties tot nu toe betreffen een uitbreiding met één snapshot. Zelfs als wijzigingen over 

een langere periode worden overgenomen, dan worden ze ingedikt tot één enkele merge of copy. 

Daarnaast is er een synchronisatie methode die elk detail van de courses kopieert. Dit wordt cloning 

genoemd. De eerste toepassing is natuurlijk het testen van Climbexion: het uitgangspunt van een 

test wordt gekopieerd en de kopie wordt gewijzigd door de test. De tweede toepassing betreft het 

leren van Climbexion, waarbij de leerling wijzigt in een kopie. Als je behalve het kopiëren ook in 

staat bent de kopie van een drawer af en toe of geregeld aan te vullen met met de de laatste 

uitbreidingen van de courses, dan is Climbexion aardig op weg om geïmplementeerd te kunnen 

worden als zuiver gedistribueerd systeem. Nu is het de vraag of zo'n kopie exact gelijk is aan het 

origineel. Een bit voor bit vergelijking zegt waarschijnlijk: ja hoor ze zijn precies gelijk. En zo is 

het ook, beide geven ze de historie weer die het origineel heeft ondergaan. Dat is ook meteen het 

verschil: de clone heeft die historie helemaal niet ondergaan, het is louter informatie, over een 

werkelijkheid die zich heeft afgespeeld in het origineel. De event en transaction timestamps in de 

clone zijn pure “valid times” waar ze in het origineel zeker ook “transaction times” zijn. Stel dat je 

besluit om op clones wijzigingen toe te staan, dan bevat de course events die de werkelijkheid van 

het origineel weergeven, en events die die de werkelijkheid van de clone weergeven, dan is dit een 

vervaging. Ik vind het een kleine frustratie van één van de uitgangspunten: “het opslaan van de 

Pagina: 125 / 230




historie, je weet nooit waar het goed voor is”, ik raad het af, wees liever precies in de duiding van 

de werkelijkheid. Een clone hoort uitsluitend informatief te zijn, en geen zelfstandige ontwikkeling 

te hebben. Je kunt altijd nog een nieuwe drawer maken die is gebaseerd op een snapshot van de 

clone, en daarin wijzigen. 

Ik denk dat, als clones volledig geïmplementeerd worden, dat het dan het beste is om Climbexion de 

transaction time van een synchronisatie te laten bijhouden. De transaction time is de tijd waarop de 

clone wordt uitgebreid met de laatste course gegevens. Omdat een clone niet altijd up-to-date is kan 

hij aanleiding zijn tot fouten en misverstanden. Als je weet waarom een fout is gemaakt, dan kun je 

beoordelen of er mogelijk nog meer fouten zijn gemaakt. (Kennis van de oorzaak kan soms 

verontrustend en soms geruststellend zijn). De transaction time kan daarbij mogelijk helpen, samen 

met de discipline om een clone consequent bij te werken vanuit één referential drawer, bij voorkeur 

het origineel, en niet vanuit verschillende (niet volledig up-to-date) clones. 

Om een volledig gedistribueerd systeem avant la lettre te maken is nog het volgende nodig. Naast 

de drawer die gekloond wordt zijn er ook nog de pools met versions en kins. Het moet ook mogelijk 

zijn om een uittreksel uit een pool te maken en te onderhouden in een “local pool”, die de drawers 

van de locatie bedient. Deze bediening betreft zowel de clones, als de lokale originelen. 

Wijzigingen moeten in andere local pools worden doorgevoerd, als op die locatie wijzigingen 

worden overgenomen. Dit betreft zowel snapshotgewijze overnames, als coursegewijze overnames. 

Envelopes horen in principe bij een constellation. Ze horen zichtbaar te zijn voor ieder die de 

center-drawer onderhoudt of analyseert. Voor de pool met envelopes geldt waarschijnlijk hetzelfde 

als voor de pool van versions: als er op locatie references staan naar envelopes dan moet de 

envelope zich in de betreffende local pool bevinden. Daarboven geldt voor een envelopes die 

“prepared” of “transfered” is, dat die teamgenoten moet kunnen informeren, zelfs als er nog geen 

reference bestaat in hun locaties. 

Als changesets bijgehouden worden in één element in een drawer, dan is een drawer de eenheid van 

cloning. Mochten we besluiten om ieder package een changeset element te geven dan is een 

package de eenheid van cloning, en is er in een drawer een mix van clones en originals mogelijk. 

Geabonneerde packages in een team drawer zouden een clone kunnen zijn van zo'n package in de 

import-drawer, tenminste als je baseline supplements realiseert in de import-drawer. Als je baseline 

supplements realiseert in de team-drawer, dan kunnen import-drawers clones zijn van exportdrawers. 

Vooralsnog lijkt er geen belangrijke toepassing te zijn voor cloning per package. 

Als het komt tot een vergelijking tussen een lokale clone van een center-drawer en daarop lokale 

branches ten opzichte van een center-drawer enerzijds en alleen lokaal een satellite anderzijds dan 

heb ik het volgende bedacht. 

1. In een satellite moet je met exact copy een base creëren voor de volgende wijziging. In een 

lokale clone is de base voor de branch reeds aanwezig. 

2. Als je tussentijds of tenslotte je wijzigingen gaat baseren op andere snapshots dan betekent 

dit voor Climbexion dat een nieuwe base wordt overgenomen uit de center drawer, dit 

overnemen hoeft niet bij een DAG 

3. Een clone moet worden bijgehouden. Als je er geen hebt hoef je die ook niet bij te houden. 

4. De privacy lijkt gelijk. De satellites blijven privé op je PC, maar de clone met branches ook. 

En slechts de resulterende changesets worden overgedragen naar de community. 

5. De clone biedt een volledige historie, met voordelen voor offline werken, de satellite en ook 

de branch slechts de historie van de snapshots die nodig waren voor de wijzigingen. 

Pagina: 126 / 230




6. Een branch is altijd afhankelijk van een trunk, voor bases en originals , een satellite bevat 

zelf alle relevante informatie. Een course in een drawer is eenvoudiger dan een DAG. 

7. Een drawer is flexibeler dan een branch, want je kunt een satellite (her)synchroniseren met 

een center-drawer, en met een transfer-drawer, zelfs met een drawer van een ander project. 

Een branch aan een clone kun je synchroniseren met de clone. (zie afbeelding). 

8. Met drawers is er een uniforme methode voor family members, projects, satellites en 

dergelijke: er is één begrip: de drawer. Met DAG's zijn er twee begrippen: de DAG en de 

branch. Je moet min of meer arbitraire beslissingen nemen wanneer je een nieuwe DAG 

begint, en wanneer een nieuwe branch, en bovendien moet je besluiten of de trunk van een 

DAG een clone is van een branch uit een andere DAG. 

9. Je kunt op een drawer de security van het file system op toepassen. Dit kan niet bij een 

branch. Het revision control systeem moet zijn eigen zijn eigen security onderhouden, als 

branches anders toegankelijk moeten zijn dan trunks, of als iedere branch zijn eigen 

toegangs-rechten heeft. 

Pagina: 127 / 230 

Satellite versus clone/branch 

manier van werken: zoals beschreven voor satellites




Al met al lijken branches qua performance superieur ten opzichte van de satellites. Immers als je 

werkt met steeds dezelfde satellite, dan kun je niet werken aan meerdere problemen tegelijk, en 

werk je met een satellite per probleem, dan is er zeker een performance achterstand. Ik hoop dat het 

effect van punt één beperkt is, omdat courses geen versions bevatten, maar slechts verwijzingen 

ernaar, maar bij de start van een satellite wordt een compleet snapshot gekopieerd, en niet slechts de 

wijzigingen ten opzichte van de vorige keer. Punten twee en drie zullen elkaar wel opheffen qua 

performance, voor een gebruiker is punt drie een aparte handeling, maar bij punt twee is de actie 

van Climbexion mogelijk geïntegreerd met de merge zelf. Voor thuiswerken en werken op reis is het 

vijfde punt ook een voordeel, maar niet uitgesloten als je werkt met een satellite. Punt zes lijkt 

vooral een implementatie voordeel voor de ontwikkelaar van Climbexion, en misschien ook voor 

een gebruiker die niet echt een lokale clone nodig heeft, er zou toch een tendens kunnen zijn om te 

gaan werken met “clouds”. 

Al met al lijkt een feature waarbij een satellite zich kan funderen op een snapshot in een andere 

drawer, zonder dat daarbij het snapshot daadwerkelijk wordt gekopieerd zeer wenselijk. Op het 

performance verlanglijstje staat primair de wens om een drawer te beginnen met een snapshot 

reference, maar misschien zou in principe elke base tag een reference mogen zijn. Of misschien 

moet ik voor satellites een uitzondering maken en branches toestaan. 

Een simpel snapshot model zou volstaan. De snapshots vormen bijna een caterpillar tree. Een 

caterpillar tree heeft een lange stam en daaraan korte branches van één edge. De stam bevat 

adjacent synchronisaties van de satellite met de de center-drawer, in de branches worden de 

problemen opgelost en de envelopes voorbereid. De korte branches zijn wel wat langer dan één 

snapshot, dus het is geen echte caterpillar tree. Door de structuur simpel te houden blijft het 

nummeren van snapshots simpel. Bijvoorbeeld, de snapshots van de stam krijgen een volgnummer, 

de korte takken heten naar het probleem dat ze oplossen, en het snapshot waarop ze zich baseren. 

De snapshots in de branches krijgen een lokaal volgnummer. Het bepalen of twee course items van 

een element een ancestor relatie hebben zou simpel moeten zijn, en ook het vinden van een “live” 

course item gegeven een snapshot zou zo betrekkelijk simpel moeten zijn, zonder een snapshot tree 

te hoeven raadplegen. Voorlopig is dit alles voorbarig. 

Ik zag een promotie video van Linus Torvalds over Git. 

Kanttekeningen bij enkele opmerkingen: 

Er is de stelling: met clones is backup overbodig. 

Het probleem met backups is toch wel dat restore maar zo zelden voorkomt. Als het eens 

onverwacht nodig is, na een crash of zo, dan sta je met het angstzweet op het voorhoofd af te 

wachten of het allemaal wel goed gaat. Van clones die op locatie daadwerkelijk gebruikt worden, 

weet je in ieder geval dat de clone hoogstwaarschijnlijk correct is, en leesbaar. Je hebt dus nog 

voornamelijk te maken met het probleem dat de clone niet 100 procent up-to-date hoeft te zijn: de 

tip van het origineel kun je kwijt zijn. Dit probleem geldt overigens ook voor een periodieke backup, 

maar mogelijk niet bij een systeem met logging, of bij het gebruik van RAID. Dus een aanvulling 

kan gewenst zijn. Zo'n aanvulling kan natuurlijk een werkwijze of procedure zijn waardoor altijd 

minstens één clone up-to-date is. 

Recovery van een software fout in de climbexion software zelf, of van sabotage of van een fout 

tijdens onderhoud door een systeembeheerder, eist mogelijk dat je terug moet naar een eerdere 

Pagina: 128 / 230




versie van een drawer. (Zelf heb ik ooit, in de rol van systeembeheerder, een restore gedraaid in 

plaats van een backup, we werkten met een zoon, vader, grootvader systeem, met rouleren van de 

backup schijven). Ook moet je er rekening mee houden dat te laat ontdekte fouten kunnen zijn 

uitgezaaid in clones, pools, satellites, backups, en log-files, waardoor je terug moet naar een oude 

backup. Dit kunnen fouten zijn die geheel of gedeeltelijk de course of development onbruikbaar 

maken. De recente historie ben je dan na restore voorgoed kwijt en moet je mogelijk vervangen 

door opnieuw wijzigingen aan te brengen. Ik denk dat ik voor de zekerheid toch periodieke backups 

zou bewaren. 

Veel van de problemen die een recovery veroorzaken zijn te voorkomen met procedures en 

(geprogrammeerde) controles, en zo. Maar toch, clones in hun eentje zijn mogelijk geen afdoende 

backup middel bij een worst case scenario. 

Als belangrijk argument wordt vermeld om met clones te werken: je kunt offline werken, zonder 

internet, VPN of intranet. Zo kun je werken in de trein van werk naar huis, en vice versa. Bij NXP 

zijn ze niet onder de indruk. 

Er is nog enige concurrentie van het systeem “planning-items” of “work-items”: problem reports, 

delta requests, en change requests, en de rapportages daarop. Een clone van een deel van dit 

systeem kan ook handig zijn. Ook hierin is een ontwikkelingsgang te volgen. Als je zou moeten 

kiezen, dan is het maar net wat je gewend bent. Waarschijnlijk hoef je niet te kiezen: als je toch 

bezig bent kun je ook hieruit kopiëren wat je nodig denkt te hebben, en dit lokaal opslaan. 

De methode om de transaction te zoeken die de fout veroorzaakte is een belangrijke methode, maar 

het is niet de enige methode, immers de fout bevindt zich in de tip en kan zonder volledige historie 

gevonden worden. Ook als je de envelope kunt aanwijzen waarbij de fout zich begon te 

manifesteren, dan is dat vaak een begin: een fout kan ontsloten zijn door de wijziging, en ook kan 

het zijn dat te weinig files gewijzigd zijn bij de implementatie van een work-item. De analyse 

hiervoor kun je plegen op de tip, je hebt de complete courses niet nodig. Kortom een clone is 

handig maar niet per se noodzakelijk. Soms, bijvoorbeeld bij ontbrekende delta processing, levert 

de zoektocht door de snapshots geen resultaat op. 

Die volledige historie moet je met een korreltje zout nemen, baselines van niet eigen packages en 

adopt merges betekenen een course indikking. De details ervan bevinden zich vaak niet in de teamdrawer. 

Import limitations kunnen files weglaten uit een team-drawer maar zijn wel te vinden zijn 

in andere drawers. Een internet verbinding is dan wel gewenst. Sommige drawers zijn niet direct 

door iedereen benaderbaar, en van de packages die erin worden bijgehouden krijg je slechts die 

files waarvoor geen export restricties gelden. Dan moet je soms mensen benaderen met een vraag 

of een probleem. Een telefoon is dan ook wel handig. 

Als je wijzigingen wilt overnemen uit sister projects, dan heb je ook daarvan misschien een clone 

nodig, maar liefst een internet toegang. 

Wat je echt mist is een test omgeving, de lab tafel, de 60 inch televisie, de satelliet schotel en zo. Die 

krijg je niet zomaar in en op de trein. Dus testen en debuggen kun je hoogstens met unit tests. 

Debuggen op de televisie is toch ook een zeer belangrijk hulpmiddel om de oorzaak van een fout te 

vinden. De clone is een halve oplossing, waarbij je slechts een deel van je werk kunt doen. Helaas 

ben je offline, dus remote debuggen en testen is ook geen optie. 

Pagina: 129 / 230




Handicap schatten. De handicap range is 0



2.5 Planning & Tracking en Repositories 


2.5.1 Introductie 

Work-items (of planning-items) zijn interessant omdat er items zijn waarnaar verwezen wordt in 

envelopes en patches en mogelijk satellites. Zo zijn er development, delta-process, change, 

problem, test, maintenance, integration, patch items en misschien nog wel meer. De items waarnaar 

verwezen wordt zouden in principe net zo lang moeten bestaan als het revision control system zelf, 

om te voorkomen dat de verwijzing iemand in de toekomst blij maakt met een dode mus. Van het 

één komt het ander, als je deze items opneemt in een eeuwig durende file, waarom dan niet alle 

work-items waarop in het project het werk en de voortgang wordt gecontroleerd? 

Een work-item heeft een voortraject. De meeste Problem reports komen voort uit tests door testers, 

sommigen uit reviews of uit debugging door ontwikkelaars, sommigen uit field calls. We maken 

nog onderscheid of het problem is gevonden door het eigen team, of door een ander. Change 

requests komen voort uit gewijzigde inzichten, of een gewijzigde markt, en uiteindelijk via de 

opdrachtgever. Delta-process en Nieuwbouw items komen voort uit requirements en uit een nieuwe 

omgeving. Patch items kunnen voortkomen uit een behoefte een bepaalde voortzetting in de 

software ontwikkeling te faciliteren. En zo moet er soms verschillend over worden gerapporteerd. 

Een opdracht om te testen kan wel een work-item zijn, maar is geen opdracht om software te 

wijzigen. Een integratie opdracht kan betekenen dat een bepaalde drawer wordt bijgewerkt met 

bestaande software. 

Work-items hebben een W.B.S. (work break down structure). Er is een W.B.S. als een work-item 

moet worden gesplitst om te worden uitgevoerd door meerdere subprojects. Voor wat betreft items 

die leiden tot een wijziging van de center-drawer of tot patches geldt in ieder geval dat ze moeten 

worden opgesplitst tot er een item voor een enkele package is bereikt. Een item dat opgedeeld is 

blijft zelf bestaan. Zijn status is de gezamenlijke status van zijn onderdelen. En het is klaar als alle 

onderdelen klaar zijn. 

Op een work-item kunnen activities worden uitgevoerd. Zo'n activity wordt gekenmerkt door een 

stadium. Voor de meeste work-items is er een vastgesteld arsenaal aan te doorlopen stadia. De 

voortgangsmanager heeft enige speelruimte voor stadium overgangen, zoals terugverwijzen naar 

een voorgaand stadium, het item aborteren, het item op ijs zetten en zo. In NXP geldt: activities 

worden gekenmerkt door twee stadia. Bij het stadium “analyze” hoort het stadium “analyzed”, bij 

het stadium “implement” behoort het stadium “implemented”, na een gebiedende wijs volgt een 

voltooid deelwoord. Alleen start en end stadia zijn singles. Een gebiedende wijs stadium wordt 

gestart door de voortgangs-manager die iemand aanwijst om de betreffende activity uit te voeren en 

daartoe een opdracht formulering kan toevoegen aan het item. Degene die de opdracht krijgt 

probeert zo snel mogelijk een verslagje toe te voegen aan het work-item, en vult enige attributes in, 

om daarna het bijbehorend voltooid deelwoord stadium te starten, zodat de voortgangsmanager 

weer aan zet is. Als neveneffect (gezien vanuit het work-item management system) zijn er dan in de 

wereld, – bijvoorbeeld in het revision control system –, dingen veranderd, getest of uitgezocht. 

Misschien is het beter om algemene voltooid deelwoorden te gebruiken , die voor alle stadia gelden: 

“interrupted” als teruggemeld wordt als de betreffende activiteit om de een of andere reden niet is 

voltooid, en “completed” als de uitvoerder vindt dat het stadium met de betreffende activiteit is 

Pagina: 131 / 230




afgerond. Of misschien zou de uitvoerder een aanbeveling kunnen doen voor het volgende stadium: 

dus “verified” met als aanbeveling: “for baseline” of “implement again”; en “analyzed” met als 

aanbeveling “reject” of “analyze again” of “implement”, of “break down”. 

De ontwikkeling van de WBS en het doorlopen van stadia vindt gelijktijdig door elkaar plaats. 

Bijvoorbeeld een analyse activity kan leiden tot een ontwikkeling van een WBS structure van het 

work-item ten behoeve van daarop volgende implement activities. 

In TV software, en in de teams herkent men een aantal competences, dwars door de lagen en de 

teams heen kan men spreken over front-end, audio, video, performance, start-up, zapping 

enzovoort. De competences zijn nodig voor een work-item, om te worden ingeschat voordat het 

wordt toegekend aan een subproject, of verdeeld wordt over de subprojects. 

De stadia vormen een course of development, ze volgen elkaar op, en als het ene stadium geldt, dan 

geldt er geen ander, het zijn successions. De verslagen en de opdracht beschrijvingen die geleverd 

worden zijn geen course of development, het ene verslag vervangt niet het andere, alle informatie is 

tegelijk geldig, het zijn hoofdstukken die toegevoegd worden. Een attribute als “uren besteed” 

bijvoorbeeld. Als het work-item 2 maal de stadia analyze en analyzed doorloopt en de eerste keer 

wordt gemeld dat er 3 uur besteed zijn en de tweede keer dat er 2 uur besteed zijn, dan vervangt de 

tweede melding de eerste niet: er zijn 5 bestede uren gemeld. Het is geen course maar wel een log. 

Activities kunnen een composition structuur hebben. Bijvoorbeeld: in een baseline test worden de 

verifying activities van andere work-items uitgevoerd, terwijl het test stadium van het baseline 

work-item wordt gerealiseerd. De test activity van het baseline work-item is een compositie van een 

aantal verify activities van diverse work-items, dus eigenlijk het omgekeerde van work-break-down. 

Zo'n planning en tracking systeem heeft best wel een interessante structuur voor een database 

ontwerper. 

Net als envelopes kunnen work-items worden overgenomen in parallelle subprojects, dus naast 

parent/child (w.b.s) relationships kunnen er siblings zijn. 

We kunnen ons voorstellen dat elk subproject zijn eigen planning & tracking systeem beheert met 

work-items. We kunnen het ons niet alleen voorstellen, zo was de situatie in de projects waaraan ik 

deelnam. Maar WBS, siblings en zo kunnen refereren dan aan items in diverse systemen. Verslagen 

en status wijzigingen van children moeten bereikbaar zijn vanuit parents en vice versa. 

Belanghebbenden, die notificaties wensen kunnen zich in andere teams bevinden. Het geheel moet 

zijn te overzien in het masterproject, ook als items daar niet zijn ontstaan. Distributie en 

confidentiality problemen zijn hier een grote uitdaging. Tussen NXP en Philips SC was dit geregeld. 

Dit is een separaat systeem, buiten Climbexion. In Climbexion zijn work-items slechts opgenomen 

als attribute in een envelope. Het moet mogelijk zijn dat Climbexion controleert of het work-item 

bestaat en gebruikt mag worden, en om er een verwijzing naar een envelope aan toe te voegen. 

Naast de work-items waarnaar verwezen kan worden in envelopes zijn er nog andere shared 

phenomena: de packages, projects, teams, mensen en dergelijke. Voor teamwork, fout-reconstructie 

en dergelijke vormt een dergelijk systeem een onmisbare aanvulling op Climbexion: het is een 

ander deel van Software Configuration Management, net als Build Management. 

De probleem beschrijvingen en de analyse en implementatie rapporten die aan work-items kunnen 

worden toegevoegd zijn natuurlijk alleen dan nuttig als ze ook worden gelezen. Als een rapport 

aangeeft, dat een wijziging nogal wat vergt, kan besloten worden om een simpeler oplossing te 

Pagina: 132 / 230




zoeken, of soms, om de wijziging niet te implementeren, of zelfs om de wijziging terug te draaien, 

als er reeds aan begonnen is. Als ieder in het team ze leest , bijvoorbeeld voorafgaand aan een 

voortgang bijeenkomst dan kunnen mogelijk vroegtijdig problemen met parallelle wijzigingen 

gesignaleerd worden. Misschien zijn de wijzigingen dan al ingevoerd, want vaak analyseert en 

implementeert iemand meerdere items per dag, maar het is altijd nog eerder dan een signaal uit een 

regressie test: volledige regressie tests vinden plaats voordat een audit start. Hoe houd je de 

discipline erin? Door elkaar erop aan te spreken als de rapporten niet gelezen blijken te zijn, of als 

ze nietszeggend lijken te worden. 

Het commentaar dat je kunt invullen als je een activiteit uitvoert moet zinvol zijn. Wat is nu zinvol 

commentaar dat je invult voor de analyze activity? Bij een gewoon problem report gaat het 

allereerst om het reconstrueren van probleem: beschrijf hoe het probleem onder diverse 

omstandigheden kan worden gereproduceerd. Dan een afbakening de software die gewijzigd moet 

worden, en tenslotte om een inschatting van de impact van de wijziging, en misschien van de 

risico's als de wijziging niet en als die wel wordt doorgezet. 

Het commentaar dat je kunt invullen als je een activiteit uitvoert moet zinvol zijn. Wat is nu zinvol 

commentaar dat je invult voor de implement activity? Elders heb ik beschreven dat een merge niet 

altijd toereikend is als je wijzigingen overneemt. Hier zou je een poging kunnen doen om te 

beschrijven waarmee je zelf rekening hebt gehouden toen je de wijziging implementeerde, en 

waarmee iemand rekening moet houden als die jouw wijziging wil adopteren. Dit commentaar moet 

natuurlijk al beschikbaar zijn als je een envelope overdraagt, immers een ander zal je gewijzigde 

software mogelijk gebruiken als een nieuwe base voor zijn eigen wijzigingen, en daarmee jouw 

wijzigingen adopteren in zijn satellite. Misschien moet er wel een pseudo-taal voor ontwikkeld 

worden. 

2.5.2 Relaties met envelopes 

Envelopes kunnen verwijzen naar work-items, en ook de inverse relatie wordt bijgehouden: een 

work-item wijst naar de envelopes. 

Een work-item kan het stadium verify met succes hebben doorlopen, en nu is baseline aan de beurt. 

In deze stadia, of in een eindstadium, of in een “on ice” stadium mag er geen envelope gecreëerd 

worden die naar dit item verwijst, dat mag alleen na een “implement” opdracht en voordat er een 

“implemented” melding is geweest. Na een “baselined” melding (met aanbeveling “end”) is het 

work-item voorgoed afgesloten. In eerste instantie zou je zeggen dat er nooit een successor 

envelope gemaakt mag worden nadat het resultaat van een work-item baselined is. 

Het op te lossen problemen is nu: stel een probleem wordt uiteindelijk opgelost in de baselinedrawer 

(en zijn satellites) en pas daarna in de team-drawer. Het work-item raakt dan baselined, maar 

is toch nog niet af. Het is pas compleet klaar als de wijziging ook is aangebracht in de team-drawer. 

Deze situatie is herkenbaar omdat er envelopes zijn voor de baseline-drawer, met een adopt 

envelope voor de team-drawer. De volgorde is nu bijvoorbeeld: (verify verified), (baseline, 

baselined), (finish, finished). Tijdens finish worden de adopt envelopes gebruikt om de wijziging te 

implementeren in de team-drawer. Daarna moet het work-item toch wel echt geëindigd zijn. Mocht 

er dan nog een fout opduiken, dan wordt die gerealiseerd met een nieuw work-item. 

Een work-item mag natuurlijk niet reeds in het stadium verify, gebracht worden als het niet eerst 

“implemented” is verklaard (met als aanbeveling “verify”). Voor de opdracht “verify” is het verder 

Pagina: 133 / 230




nog nodig dat er geen envelopes in uitvoering zijn (behalve één voor “finish”), en dat er minstens 

één het envelope stadium “implemented” heeft gehaald. Menselijk beslissen lijkt toch noodzakelijk. 

Stel je voor dat in een succession van twee envelopes de laatste een “undo” realiseert van de eerste, 

dan verifieer je toch wat anders, dan wanneer de undo ontbreekt. Of dat in een succession van drie 

envelopes de derde een “undo” realiseert van de eerste, dan wil je toch wel een extra verklaring van 

voltooiing, voordat “verify” start. 

In zijn algemeenheid geldt waarschijnlijk dat de envelopes van een work-item moeten zijn 

beëindigd (“implemented” of “rejected”) voordat het “implement” stadium van het work-item wordt 

verlaten. 

2.5.3 Composite Activities 

1. Baseline samenstellen 

Het is de bedoeling dat de gegevens in het work-item systeem gebruikt worden bij het 

samenstellen van de baseline. Hier volgt een scenario: 

● Allereerst wordt met exact copy de tip van de baseline-drawer gelijk gemaakt met die van 

de team-drawer. 

● Daarna vinden er, in de baseline drawer, undo operaties plaats van wijzigingen die nog niet 

vrijgegeven moeten worden. De work-items die hierbij een rol spelen zijn die work-items 

die slaan op het betreffende package, die te maken hebben met software wijzigingen, en die 

niet “verify” hebben bereikt, of zijn gestopt. Het lijstje “undo”work-items moet het liefst 

met een query gemaakt kunnen worden. 

● Dan is het zaak de lijst te preciseren. Bijvoorbeeld: sommige work-items moeten alsnog 

worden geïmplementeerd en geverifieerd, die moeten uit deze lijst verwijderd worden. 

● Dan moet de work-item lijst vervangen worden door een envelope lijst, van die envelopes 

in de team-drawer waarvoor een undo envelope gemaakt moet worden voor de baselinedrawer. 

Dit is ook een query of een script. Ook moet er een script worden uitgevoerd dat de 

undo envelopes voor de baseline-drawer prepareert. 

● De undo envelopes worden gerealiseerd, waarschijnlijk als comrade envelopes die 

gezamenlijk moeten worden overgedragen. 

● Vaak worden in de baseline-drawer soms nog (kleine) wijzigingen geïmplementeerd. 

● De lijst met work-items in de toestand verify, kan gebruikt worden voor het verify deel van 

de baseline test. 

● Na verificatie (de baseline test) moeten er mogelijk nog meer undo of redo operaties 

worden uitgevoerd. Die kunnen verzameld worden door een query voor verified work-items 

met een “implement” recommendation. De work-items met een “baseline” recommendation 

hoeven natuurlijk niet te worden geselecteerd voor undo of redo. 

● Nadat de baseline is gerealiseerd moet er een “baselined” melding plaatsvinden op de 

betreffende work-items, de meeste met aanbeveling “end” maar sommige met de 

aanbeveling “finish”. Voor deze laatste moet er een adopt envelope worden aangemaakt die 

afgeleid is van de envelope in de baseline-drawer. Dit alles wordt mijns inziens gerealiseerd 

met een script, als een composite activity. 

● Tenslotte moeten er nog query's worden uitgevoerd ten behoeve van het baseline report: om 

de lijst met opgeloste work-items te documenteren. 

Pagina: 134 / 230




2. Het synchroniseren van de eigen package met die uit een ander project. 

Van de work-items in het sister-project die worden overgenomen moeten siblings gemaakt worden 

in het eigen project: dat kan deels met een script. Deze siblings moeten uiteindelijk allen op 

implemented uitkomen. Meestal zal men synchroniseren met de export-drawer van het sisterproject. 

De work-items die erbij betrokken zijn zijn te verkrijgen met een query: alles wat baselined 

is sinds de voorgaande synchronisatie. Deze work-items worden gesplitst in drie lijsten: 

● één voor de over te nemen work-items. (hiervan worden sibling work-items gemaakt) 

● één voor de niet over te nemen items. (hiervan worden undo envelopes gemaakt voor de 

merge-import-drawer) 

● één voor de reeds gerealiseerde work-items, waarvoor reeds siblings bestaan. (hiervan 

worden undo envelopes gemaakt voor de merge-import-drawer) 

Alle undo envelopes zijn comrades die refereren aan het adopt work-item. 

De composite activity bestaat uit: 

● Als we veronderstellen dat het snapshot met originals reeds aanwezig is in de betreffende 

merge-import-drawer: exact copy van het snapshot met potentiële neighbors. Dit wordt het 

snapshot met originals voor de volgende keer. De copy plaatst de tip (of een baseline) van 

de export-drawer van het sister-project in de merge-import-drawer. 

● We realiseren de undo envelopes in de merge-import-drawer. De nieuwe tip van de mergeimport-drawer 

bevat de uiteindelijke neighbors. 

● We realiseren een globale merge via een satellite in de team-drawer. Dit gebeurt op de 

gebruikelijke manier: eerst nemen we de tip-tag van de team-drawer als base, dan vinden 

builds, tests en plaats, en worden verbeteringen aangebracht, en tenslotte wordt het resultaat 

gebaseerd op de tip van de transfer-drawer, en overgedragen. 

● Dit vindt plaats onder toezicht van de composite activity van een “adopt” work-item dat de 

gehele synchronisatie begeleid. Als dit work-item de melding implemented ontvangt 

worden ook de sibling work-items op implemented gezet. 

3. Adopt en undo operaties tijdens groeps-operaties. 

Er kunnen work-items zijn die zelf niet refereren aan een envelope, bijvoorbeeld omdat ze met een 

groeps-operatie (merge vanuit een ander project) zijn geïmplementeerd. Deze work-items zijn 

siblings van andere work-items die mogelijk wel een envelope hebben, of die zelf weer 

geïmplementeerd zijn met een groeps-operatie, enzovoort. Via work-item siblings is er altijd wel 

één te vinden met een envelope, of een set envelopes (envelope comrades en envelope successors). 

Van die work-item siblings die met envelope zijn implemented kan er één gekozen worden voor de 

adopt of undo operatie. Misschien kan een script de meest geschikte kandidaat vinden, maar 

voorlopig ga ik er maar vanuit dat je er een mens voor nodig hebt. 

4. In plaats van adopt merge werken met een zwerm adopt envelopes 

Deze methode is aan te bevelen indien er veel wederzijdse uitwisseling bestaat. Immers tussen 

originals en neighbors zijn veel gemeenschappelijke wijzigingen gerealiseerd in beide subprojects. 

Die wijzigingen hoef je niet meer over te nemen. Ook kunnen er veel wijzigingen zijn gerealiseerd 

in het andere subproject die je niet wilt overnemen. Kortom als het aantal “undo” envelopes 

aanzienlijk wordt, dan is de zwerm zeker aan te bevelen. 

● Er vinden selecties plaats op de work-items in het andere subproject om een lijstje work- 

Pagina: 135 / 230




items te krijgen waarvan de siblings in het eigen project moeten worden gemaakt. 

● Het lijstje work-items wordt gebruikt om die envelopes te vinden waaruit adopt envelopes 

moeten worden gemaakt. 

● Een script maakt de sibling work-items in het eigen package, en de envelopes voor de 

betreffende merge-import-drawer. 

● Met exact copy wordt het snapshot base versions binnen gehaald in de merge-importdrawer. 

Dit is de tip van de eigen team-drawer. 

● De adopt envelopes worden hierop gerealiseerd, (met behulp van een satellite van de 

merge-import-drawer). Eventuele aanvullende wijzigingen worden gerealiseerd. In dit 

drawer en zijn envelopes zijn alle details terug te vinden. 

Een verschil met adopt merge, voor zover het de groep activity betreft: 

● Een merge vindt plaats naar een satellite van de team-drawer, op de gebruikelijke wijze 

zodat daar een ingedikte overname plaatsvindt, zoals bij adopt merge. Hier wordt ook een 

overgang gerealiseerd: eerst was een tip-tag van de team-drawer de base, nu kan men de 

wijzigingen baseren op de tip van de transfer-drawer. 

● Adopt zwerm: Het work-item voor de merge refereert aan de envelope in de team-drawer 

waarmee de merge wordt gerealiseerd, maar alle siblings bevatten een envelope waarmee 

de individuele implementatie in de merge-import-drawer is gerealiseerd. 

Adopt merge: Het work-item refereert aan alle envelopes: de undo envelopes en de merge 

envelope. De sibling work-items bevatten geen envelope referentie. 

De zwerm heeft als voordeel dat alle wijzigingen gerelateerd zijn aan envelopes in de sibling workitems, 

ook eventuele aanvullende wijzigingen die voortkomen uit build en test resultaten. Dit maakt 

de zwerm aantrekkelijk ten opzichte van de adopt merge met undo. 

Pagina: 136 / 230



2.6 Builds en Repositories 


2.6.1 De invloed van builds op Climbexion 

Het build proces gebaseerd op recent timestamp. 

Normaal wordt een build uitgevoerd door een build programma aan de hand van een scrip file. De 

uitvoering bestaat uit twee delen. Deel 1 creëert een directed graph en deel 2 gebruikt de graph voor 

generen, compileren en linken. Deze 2 fasen methode is de way of working als je Koala gebruikt. 

In wezen is de graph een data flow diagram. In wezen is de graph een workflow diagram. Minstens 

één van beide zal wel waar zijn. 

De graph bestaat uit 2 soorten nodes, file nodes en script nodes. File nodes bevatten een verwijzing 

naar een file, en script nodes bevatten een script. 

Zo'n script beschrijft meestal een compilatie en roept een compiler aan, of het is een link 

procedure,en roept een linker aan, maar in zijn algemeenheid kan het ook een programma of een 

script aanroepen dat compileerbare code genereert uit plaatjes of specificaties. 

Een script node heeft een aantal input nodes, dit zijn altijd file nodes. In de graph zijn het de directe 

voorgangers van het script. Ze worden wel de “dependency list” van de scrip node genoemd. Een 

script node heeft ook één of meer output nodes, dit zijn ook altijd file nodes, en ze volgen 

rechtstreeks op de script node. Alleen die outputs van een script worden opgenomen in de graph die 

nodig zijn om de end-node te bereiken, maar eventuele andere output files van het programma dat 

door de script node wordt aangeroepen worden wél gegenereerd als het script wordt uitgevoerd. 

Een graph bevat een aantal begin-nodes, en één end-nodes. Begin-nodes zijn file nodes. De endnode 

is een file node die gewoonlijk een fictief target representeert. Als een build wordt uitgevoerd 

wordt één file node aangewezen als target. Bij dit target hoort een subgraph naar de “reachable” 

begin-nodes. Deze subgraph wordt gebruikt om het target up-to-date te maken. Targets zijn meestal 

executables of libraries. Het target is de end-node van de subgraph. Over het algemeen wordt in fase 

1 slechts de subgraph aangemaakt. 

Een output file die gegenereerd wordt heet ook wel een “derived file”, en een file die in begin nodes 

voorkomt wordt “source file” genoemd. Een output file die geen target is wordt wel “intermediate 

result file” genoemd. 

Een output file wordt altijd maar op één manier gemaakt. Daarom kan een script node, – indien 

nodig, – een unieke naam krijgen als hij wordt genoemd naar de file van de eerste output node. 

Vaak heeft één van de input files dezelfde naam als de output file (op een type aanduiding na). Deze 

file noemen we de primary input. Wie de andere input files zijn is dan vaak af te leiden uit de 

content van de primary input file en de content van reeds gevonden input files. 

Deel 1 formeert in het algemeen de graph, aan de hand van een script file, parameters, en de 

bevindingen in het file system. Het is niet eenvoudig om de graph zo precies mogelijk te maken. Als 

een script node meer inputs nodes heeft dan er werkelijk gebruikt worden tijdens uitvoering van het 

script, dan gaat dit ten koste van de efficiëntie van het build process. Als er minder input nodes zijn 

Pagina: 137 / 230




dan er gebruikt worden dan kan het build process een foute target genereren. Bijvoorbeeld: de build 

kan mislukken omdat de linker een oude object file gebruikt, met verouderde referenties, en zonder 

de nieuwe symbolen. 

● Er zijn ontwikkelomgevingen waarin de graph handmatig wordt bijgehouden in een make 

file. 

● Moderne IDE's houden een project-file bij, waarin alle source files staan, en met de 

aanname dat elke object file afhangt van een gelijknamige primaire source file en van alle 

header files, en dat de target afhangt van alle object-files, wordt hieruit de graph gemaakt. 

● De graph kan echter ook (deels) geconstrueerd worden door tools die de structuur van de 

graph vaststellen, door te kijken wat er in de source en header files staat. De Cpp 

preprocessor heeft bijvoorbeeld een optie om een dependency list te genereren door na te 

gaan welke header files worden gebruikt in een C of C++ programma en hun header files. 

● Voor NXP Mips software is er het Koala gereedschap dat wordt gebruikt om vast te stellen 

welke object files nodig zijn voor een target. Koala bepaalt dit aan de hand van de koala 

files. In feite kijkt koala welke Koala files gewijzigd zijn ten opzichte van de vorige keer, en 

wijzigt zo de tree van de vorige keer. 

Pagina: 138 / 230 

buildgraph




Hoe dan ook, de build scripts zijn vaak complex en net zo "under construction" als de software zelf, 

dus lang niet altijd volmaakt. 

Deel 2 voert script nodes in de subgraph uit. 

● Een node wordt uitgevoerd omdat één van de output files ontbreekt. Er is wel een output 

node maar de genoemde file staat niet in het file system. Na uitvoering van het script is de 

file er wel. 

● Een node wordt ook uitgevoerd als de timestamp van één van de input files recenter is dan 

die van één van de output files. Na afloop van het script hebben alle output files van de node 

een recentere timestamp dan de input files. 

● Een node mag pas worden uitgevoerd, als die script nodes zijn uitgeprobeerd, en mogelijk 

ook zijn uitgevoerd, die een input file leveren voor de node. 

● Er worden net zo lang script nodes uitgevoerd tot er geen aanleiding meer is: alle output 

files van elke node in de subgraph zijn er en ze zijn allemaal recenter dan de betreffende 

input files. 

In plaats van te zeggen: “de node wordt uitgevoerd”, of “het script van de node wordt uitgevoerd” 

zegt men ook wel: “de node vuurt” of “het script wordt afgevuurd” of “de node vuurt het script af”. 

Als deel 2 afgebroken wordt, bijvoorbeeld doordat een compilatie mislukt en een error code afgeeft, 

en je verbetert de fout, dan gaat deel 2 van een nieuwe build verder waar de oude is gebleven. 

Het is altijd mogelijk om een volledige build uit te voeren voor een gekozen target. Dit werkt als 

volgt: 

● iedere node in de subgraph moet eenmaal vuren. 

● Een node gaat vuren als geen van zijn input files wordt gegenereerd door een andere node 

het zijn allemaal source files. 

● Een node gaat ook vuren als alle script nodes hebben gevuurd, die één van zijn input files 

genereren. 

Dit is nodig als het geheel aan source files en intermediate result files is gecorrumpeerd, 

bijvoorbeeld omdat de timestamps niet kloppen, of omdat een fout verlopen generator wel een foute 

output file heeft gemaakt. Ook na wijziging van het build process, of van de tools die erin gebruikt 

worden is het raadzaam om een volledige build uit te voeren. De verzameling derived files kan 

gemanipuleerd worden buiten de build procedure om, dat kan corruptie veroorzaken, waarna een 

clean build nodig is. 

Het is aan de gebruiker om vast te stellen of een volledige build nodig is. Een indicatie is 

bijvoorbeeld dat een gewone build mislukt, of dat de binary zich onverwacht gedraagt. Maar als de 

volledige build dan ook mislukt, of als de binary zich nog steeds onverwacht gedraagt dan lag het 

mogelijk niet aan de build. 

Een zwak punt : 

Als er oudere source files opduiken in de working-tree dan die van derived files in de vorige 

build, dan is dat bij een nieuwe build geen aanleiding om een node af te vuren. Hier is de 

werking van het revision control system in het geding. 

Een working-tree synchroniseren levert vaak recentere timestamps op van gewijzigde files en 

altijd dezelfde timestamps voor ongewijzigde files. Maar het kan voorkomen dat wijzigingen in 

de working-tree worden tenietgedaan door synchroniseren, dan is de timestamp van een 

gewijzigde file niet per se recenter dan die van de vervangen file. We specificeren een optie die 

Climbexion laat werken op de volgende manier: 

Pagina: 139 / 230




● De timestamp wordt geleverd door het tip event van de course van de file. 

● Wanneer de working-tree wordt gesynchroniseerd met de drawer dan kan de repository 

software aan de course van een element het event toevoegen dat het element is 

gekopieerd naar de working-tree Dit is het touch event. Dit event heeft een jongere 

timestamp dan de voorgaande build, en is gelijk aan de timestamp van de working-tree 

file na synchronisatie. Het revision control system is dan nog steeds in staat om te 

controleren of kopiëren nodig is, ingeval van exact copy. 

Deze optie van het revision control system is er speciaal voor builds die gebaseerd zijn op recent 

timestamp. 

Een bekend voorbeeld van een make programma gebaseerd op recent timestamps: GNU Make. 

Een programma dat Koala lijkt te evenaren als het gaat om builds over een complexe folder 

structuur, en het scheiden van sources en derived files: Cmake. 

De opslag van tussenresultaten: 

● Elke target heeft een eigen folder voor de derived files: de build folder. Een product target 

heeft andere derived files dan een platform target, (dank zij o.m. de compile time interface 

binding van KOALA, die header files genereert voor elke c source file: een gecompileerde 

file voor een product verschilt daardoor van die voor een platform) de object modules in 

debug mode verschillen van die in optimize mode, dus voor één target kan er een folder zijn 

voor debug, en één voor optimize. 

● De .h files en c files die gegenereerd worden door de idl compiler zijn altijd hetzelfde, of ze 

nu in een platform build worden gebruikt, of in een product build, of in een component 

build. In debug mode of in optimize mode, ze zijn hetzelfde. Hiervoor wordt dan ook een 

aparte folder gebruikt, zodat de ene build kan profiteren van de tussenresultaten van de 

andere. 

Binnen de inner-reach van zo'n build folder vindt je vaak een folder structuur voor de nette opslag 

van intermediate result files. 

De targets zelf komen als member terecht in de build folder. Deze target wordt mogelijk gekopieerd 

in de inner-reach van een package, bijvoorbeeld om met het package gedistribueerd te worden. 

Het build proces gebaseerd op different timestamp. 

De studie hier is om te kijken of de build folder kan worden opgeslagen in de team-drawer na de 

acceptatie test. Als een satellite wordt gesynchroniseerd, dan wordt ook de meest recente build 

folder van de daily build beschikbaar gesteld en hoeven alleen de eigen wijzigingen te worden 

gecompileerd. 

● Een inner-reach van een build folder voor de derived files van de daily builds is voorlopig 

één enkel element in het revision control system, dat wil zeggen een archief (zip, tar) file 

van zo'n folder is een element in het revision control system. 

● De vraag is nu hoe de build procedure moet worden aangepast om builds in working-trees of 

info-trees goed te laten verlopen: 

Het build process moet niet langer testen of de timestamp van de file in een output node 

minder recent is dan dat van één van de input nodes, maar of de timestamp van de input 

node afwijkt van die van de vorige keer. Dit kan door de graph op te slaan met de 

timestamps van de betrokken files. De timestamps worden opgeslagen op de input edges van 

Pagina: 140 / 230




de script nodes, en up-to-date gebracht nadat het vuren van de script node goed is verlopen. 

● Als een file uit het revision control system wordt geplaatst in een working-tree of info-tree, 

dan moet de timestamp niet de timestamp zijn van het tip event in de betrokken drawer, 

maar de timestamp van de version. Deze timestamp is de “datum laatste wijziging” van de 

file ten tijde van de commit. Deze optie van het revision control system is speciaal voor 

builds die gebaseerd zijn op different timestamp. De optie is een een waarde van een 

attribute van de drawer. 

De builds voor platform of andere onderdelen en voor het product worden hierdoor mogelijk minder 

langdurend. In plaats van een clean build kun je dan de build folder uit het revision control system 

halen, en profiteren van de resultaten die daar reeds behaald zijn. Dit build process is mogelijk 

kwetsbaarder voor corruptie dan een build gebaseerd op recent timestamp, omdat de graph met 

timestamps permanent moet worden opgeslagen, ook nadat er een (compilatie) fout is opgetreden. 

Pagina: 141 / 230 

Edges van Begin Nodes met Timestamps




In feite gaat het om de betrouwbaarheid van een permanente gegevensbank: die kan gaan afwijken 

van de werkelijkheid. Deze kwetsbaarheid is reeds begonnen bij Koala, die gebruik maakt van een 

voorgaande data om de huidige data bij te werken, en de buildgraph te creëren. 

Meer dan bij een recent timestamp methode geldt in zijn algemeenheid: 

● Kies een gerenommeerd build tool. 

● Kies gerenommeerde compilers, linkers, generators en vooral betrouwbare tools om delen 

van de buildgraph te af te leiden. 

● Zorg voor een adequate discipline om de eigen scripts en tools bij te houden. 

● Zorg voor een adequate omgeving en discipline om de builds uit te voeren. 

● Zorg regelmatig voor clean builds. Bijvoorbeeld de dagelijkse builds in de team-drawer 

zouden clean builds kunnen zijn: hierbij kan de buildgraph opnieuw gemaakt worden. 

In feite is het voor deze timestamp methode niet per se nodig om de gehele graph op te slaan. Een 

graph bestaat uit nodes en edges. De edges vanaf een source node naar een script node zijn van 

belang. Voor elk van deze edges moet de timestamp van de source bewaard worden. Dit is 

natuurlijk minder robuust, dan een methode die alles opslaat. Het make algoritme werkt nu als 

volgt. 

● Een script node mag pas vuren als al zijn voorgangers zijn geprobeerd, en mogelijk hebben 

gevuurd. 

● Als de file van een output node ontbreekt dan kan gevuurd worden. 

● Als de file van een output node minder recent is dan die van een intermediate result input 

node, dan kan gevuurd worden. 

● Als de timestamp van een file van een source input node afwijkt van de timestamp op de 

edge, dan kan gevuurd worden. Ook als er geen timestamp bekend is van een vorige build, 

kan gevuurd worden. Als het vuren zonder fouten afloopt wordt de edge up-to-date gebracht, 

met de timestamp van de source. 

Voorbeelden van make programma's gebaseerd op different timestamp: “Alcatel-Lucent Nmake” 

(http://www.bell-labs.com/project/nmake/ ) free software: Odin (http://sourceforge.net/projects/odinbuild/) 

In plaats van een timestamp wordt ook wel gesteld dat je beter een content hash kunt gebruiken. 

Climbexion versions krijgen als interne identifier waarschijnlijk een door Climbexion gegenereerde 

content hash. Deze zou als metadata in een working-tree file kunnen worden geplaatst. Het best zou 

de hash door het edit tool kunnen worden gegenereerd bij een "save" opdracht, en berekend kunnen 

worden voor gegenereerde files, zodra die ontstaan: dus voordat een commit plaatsvindt. 

Samenvatting recent en different timestamp builds 

Climbexion heeft 2 opties: 

● Voor recent timestamp builds: Een working-tree element krijgt als “datum laatste wijziging” 

de timestamp van het laatste event in de course. Als een working-tree file opnieuw wordt 

gesynchroniseerd met de satellite (exact copy) dan wordt dit als event (touch event) 

geplaatst in de course van de gekopieerde file. De working-tree file krijgt de timestamp van 

dit laatste event. 

● Voor different timestamp builds: Een working-tree file krijgt de timestamp van de version 

(de datum laatste wijziging) of anders diens content hash. Elements zonder versions 

(folders) krijgen de geboorte timestamp van de kin, of de kin id in plaats van de hash. 

Pagina: 142 / 230




Soortgelijke opties vond ik bij Synergy. 

Het build proces zonder timestamp of checksum, gewoon voor de lol. 

De methode die ik nu beschrijf is van origine een “push” algoritme. Dit wil zeggen dat een update 

wordt gepropageerd naar alle targets. Een voorwaarde is dat er een taak (ihook) is opgestart die in 

actie komt zodra een (gewijzigde) file in de working-tree terechtkomt, een hook van de “file close” 

procedure zeg maar. Ik weet niet of er build tools bestaan die zijn gebaseerd op dit principe, in mijn 

jeugd heb ik mij hieraan bezondigd voor een software transitie van de afdeling ontwikkeling naar 

de afdeling productie. Mijn amateuristische implementatie was echter niet robuust en niet 

herstartbaar na een compilatiefout, en de methode is een stille dood gestorven. 

In de praktijk kan een wijziging van een source leiden tot een wijziging in de structuur van de 

buildgraph. De beschrijving van het algoritme houd ik hier eenvoudig door uit te gaan van een 

ongewijzigde opgeslagen buildgraph: 

De script nodes in de buildgraph worden genummerd zodanig dat een node X waarvan een 

output file input is voor een node Y een lager nummer krijgt dan node Y. Naast de 

buildgraph wordt er een heap bijgehouden. De taak ihook plaatst node nummers in de 

heap. Voor elke (gewijzigde) file die de working-tree binnenkomt wordt uitgezocht voor 

welke script nodes de file een input file is, en die node nummers worden door ihook in de 

heap geplaatst. Een build procedure haalt steeds de laagst genummerde node volledig uit de 

heap en voert die uit. Dit resulteert in nieuw gewijzigde files in de working-tree, zodat ihook 

weer (met prioriteit) in actie komt en de heap uitbreidt. 

Een en ander maakt dat het algoritme voornamelijk geschikt kan zijn voor build managers. Een 

drawer voor een build manager staat bijvoorbeeld open voor overdrachten van ontwikkelaars (met 

een overdrachtstool), en periodiek wordt de drawer gesloten en vindt de build plaats (met een build 

tool). Het algoritme zou in die situatie simpel geïmplementeerd kunnen worden, want ihook is 

eenvoudig te implementeren als een procedure in beide tools. Over het algemeen is het de vraag of 

er een ihook gemaakt kan worden die altijd en overal werkt, en je wilt de situatie vermijden dat er 

met veel regels en beperkingen gewaarborgd moet worden dat ihook werkt. 

Helaas is het niet praktisch als de build manager andere tools hanteert voor de build dan de 

ontwikkelaars. 

Eigenlijk kan het principe worden toegepast zonder heap, op zo'n manier dat file-to-script edges in 

de buildgraph gemarkeerd worden door ihook. Er zouden daarna “pull” algoritmen gebruikt 

kunnen worden. Merk op dat ihook kan markeren buiten de subgraph die bij een pull methode 

gebruikt wordt, ook als ze door het pull algoritme aan het werk gezet wordt. 

Bij de “different timestamp” methode kan eerst de structuur van de buildgraph worden bijgewerkt 

in de “deel 1” fase van de build. Daarna tijdens deel 2 van de build fase worden nieuwe 

timestamps opgeslagen. Maar bij deze ihook methode moet de buildgraph in deel 1 niet alleen 

bijgewerkt worden maar ook nog gemarkeerd worden door ihook. Het weghalen van een markering 

vindt in het build proces plaats meteen nadat de node met succes heeft gevuurd in deel 2. 

De kwetsbaarheid van ihook komt bovenop de kwetsbaarheid die reeds gold voor de “different 

Pagina: 143 / 230




timestamp” methode: de permanente opslag van de buildgraph die altijd een getrouwe 

administratie moet zijn van de werkelijkheid. Als er iets mis gaat is de graph opnieuw af te leiden 

uit de werkelijkheid, maar opgeslagen timestamps en markeringen niet. Een verschil tussen een 

timestamp in een input edge en een markering van een input edge: als de timestamp niet is ingevuld 

dan is dat een reden om de script node te laten vuren, als een markering niet is ingevuld, dan is dat 

geen reden om de node te laten vuren. 

Eigenlijk is de timestamp (of hash) van een file in een gebruikelijk file 

system geen unieke identificatie van de versie van een file: theoretisch is het mogelijk dat een 

andere versie van een file de working-tree binnenkomt die dezelfde timestamp (of hash) heeft als 

zijn voorganger. Wat dat betreft is deze ihook methode uitstekend en theoretisch volmaakt. Aan de 

andere kant als een bestaande file voor de tweede keer de tree binnenkomt, dan is een markeer 

reactie overbodig, en zou die onderdrukt moeten worden, en dat vermogen heeft mijn methode niet. 

De buildgraph lijkt wel wat op een petri-net, maar er zijn typische verschillen, Zo bevinden zich de 

tokens bij de buildgraph op de arcs van file-nodes naar script nodes (input arcs). Een script node 

(transitie) mag vuren als minstens één input arc een token bevat of als een output file ontbreekt. Als 

een token geplaatst wordt op een arc, dan verenigt deze zich met een eventueel reeds aanwezig 

token. In een petri-net bevinden de tokens zich in places, moeten alle input places een token 

bevatten voordat een transitie mag vuren, en verenigen tokens zich niet. Een script node in een 

buildgraph vuurt pas als er geen verdere plaatsing van tokens wordt verwacht op de input arcs, er 

is sprake van een gedwongen volgorde, in tegenstelling tot het non determinisme van petri-nets. 

Ik vermoed dat een buildgraph vertaald kan worden in een petri-net, maar wel één met de nodige 

extensies waardoor er weinig toegevoegde waarde is: het petri-net is waarschijnlijk niet beter 

analyseerbaar en verifieerbaar, dan de buildgraph. Het zou misschien belangrijk kunnen zijn voor 

de taxonomie: make of build software is een vorm van workflow software. 

2.6.2 First class citizens of tarballs 

Ik ga er tot nu toe vanuit dat voor Climbexion een build folder een file element is, een tarball of een 

zip file. In principe betekent dit dat grote hoeveelheden content worden getransporteerd en 

opgeslagen. Als je aanneemt dat het vooral clean builds (builds vanaf scratch) zijn die worden 

opgeslagen dan is dit mogelijk gerechtvaardigd. Het element-type "gearchiveerde folder" kan 

geïntroduceerd worden voor het opslaan van folder-structuren met derived files. 

Als je twee keer dezelfde source file compileert en je vergelijkt de content van de twee object files, 

dan blijken die soms te verschillen. Dit komt omdat in een aantal formaten van object files de 

compilatie timestamp of link timestamp deel uitmaakt van de inhoud van de files, en er niet slechts 

als metadata bij de file-id of in een file fork aan is toegevoegd. De content in een intermediate result 

file of in een target zal daarom verschillen van die van een voorganger als hij opnieuw gemaakt 

wordt. Er zijn waarschijnlijk nog andere oorzaken waardoor twee compilaties van precies dezelfde 

sources kunnen verschillen. Met simpele compare tools en checksum of hash tools herken je zo 

geen files die eigenlijk hetzelfde zijn. 

Enige mogelijke bijkomende oorzaken: 

● Niet geïnitialiseerd data geheugen, niet geïnitialiseerde gaps. 

Pagina: 144 / 230




● Non determinisme (bijvoorbeeld door het gebruik van threads tijdens compileren), 

● Linkers en library tools zijn vaak in staat om incrementeel object files te incorporeren in 

executables en libraries. Ook vervangen en verwijderen van objecten is mogelijk. Je kunt 

verwachten dat het adres van de geheugen allocatie van een object binnen de executables of 

libraries afhangt van de volgorde waarin de mutaties zich aandienen. Dit geldt in ieder geval 

voor sommige van deze tools. 

● Er zijn C macro's als “__DATE__” en “__TIME__”. De datum en tijd zouden slechts dan in 

de content van een object file mogen worden opgenomen als deze macro's daadwerkelijk 

gebruikt worden. 

● zelflerende compilers. ;-) 

Ik heb niet de indruk dat ik de volgende vraag volledig en uitputtend behandeld heb: wanneer kun je 

niet met een simpel compare tool of met een hash bepalen of twee derived files hetzelfde zijn. 

Mogelijk is een test of het wel of niet kan erg simpel. 

Misschien is mijn scepsis gebaseerd op spoken uit een ver verleden, en komen dit soort problemen 

momenteel helemaal niet voor. Toen ik in Wikipedia een vergelijking vond van formaten van object 

files, was er sprake van de mogelijkheid om metadata op te slaan in de content. Maar misschien 

wordt hiermee debug informatie bedoeld, zoals line numbers, en non external symbols. 

Gebruik je een object file formaat waarin geen metadata wordt opgeslagen in content, en een 

compiler / linker die de hele content initialiseert enzovoort, dan kan Climbexion met een simpel tool 

herkennen dat object files hetzelfde zijn, en is het efficiënt om geen tarball te gebruiken maar om 

individuele versions te vervangen en te transporteren, zelfs bij builds vanaf scratch. Als er sprake is 

van non determinisme, dan kan in de praktijk gelden dat er een reële kans is dat een object file in 

twee opeenvolgende builds op dezelfde PC gelijk zijn. Als je werkt met verschillende typen derived 

files, dan zijn sommige typen vast wel exact reconstrueerbaar. Misschien geldt dan: neem die kans 

en werk met first-class-citizens. 

Het gebruik van build procedures gebaseerd op “recent timestamp” is een belangrijke reden om 

regelmatig clean builds uit te voren, maar ik ben er van overtuigd dat het niet de enige reden is. 

Soms is een clean build aan te bevelen als source files verplaatst of hernoemd zijn, want een build 

tool kent gewoonlijk geen kin, en zou ten onrechte een verweesde derived file kunnen tolereren als 

een source file. Een build manager die bouwt voor een wijzigend team zal alleen al daarom voor de 

zekerheid regelmatig clean builds uitvoeren, liever dan nauwkeurig na te gaan wat er precies 

gewijzigd is en dan manueel te zorgen voor precies de juiste rebuild. Maar misschien is zijn er 

inmiddels goede tools, immers een source file hoort niet voor te komen in een folder voor derived 

files; een goed tool weet dat en verwijdert een verweesde file, en Climbexion hoort dit ook te weten 

en vult een nihil file in in de filestring, of wijzigt name en folder reference in de file-string 

reference. Uiteindelijk zou een clean build slechts nodig zijn bij een wijziging van de build 

software, of corruptie of verlies van de build database waarin de identifiers van de oorspronkelijke 

versions zijn opgeslagen. Misschien is een clean build nodig bij corruptie of verlies van build 

folders, maar een goed tool herkent mogelijk de corruptie en verwijdert derived files die afwijken 

van de build database, voordat de build start. 

Nu we kunnen besluiten om build results niet op te slaan als archive, moeten we maar een kijken 

naar de gegenereerde folders, zijn dat other-focused folders? Een folder is in Climbexion 

gedefinieerd als een element zonder inhoud, waarnaar andere elementen mogen wijzen. Zo'n folder 

slaat echt niet op een snapshot, maar is een gewone folder, met hooguit een entity type “build 

Pagina: 145 / 230




container”. Af en toe moet maar eens gekeken worden, of zo'n folder beëindigd moet worden. 

2.6.3 Build Forest 

Deze trend in de ontwikkeling definieert een working-tree, of een info-tree als een verzameling 

build trees, die min of meer onafhankelijk van elkaar builds kunnen uitvoeren. Zo'n build tree 

bestaat dan uit packages. Een executable (binary) die gemaakt wordt in de ene build tree moet 

kunnen samenwerken met die uit een andere als ze worden uitgevoerd in de televisie. Dit 

samenwerken kenden we reeds: een TriMedia binary moet samenwerken met een MIPS binary en 

met een 8051 binary, maar nu krijgt elke binary een eigen subtree, en er komen meerdere binaries 

voor de MIPS processor. Sommige van mijn collega's zijn bezorgd en spreken over het naderen van 

de “dependency hell”, waarmee ze runtime afhankelijkheden aanduiden. Mijns inziens wordt de hell 

pas bereikt als independent deployment wordt bereikt, en voorlopig zal ik het geen hell noemen 

maar een uitdaging. 

Om op runtime te kunnen communiceren worden interface gegevens, en referentie codes van 

servers mee gecompileerd en gelinkt met clients. De betreffende files worden gedefinieerd in een 

package van de ene tree, of in een package in de andere, of zelfs in een derde tree. De methode die 

gebruikt wordt is hetzelfde of is afgeleid van de COM methode van Microsoft. Dit houdt in dat een 

midl compiler wordt gebruikt in een build. 

Een package bevat 2 soorten shared data: 

● public binnen de build tree (local public). 

● public binnen het build forest (global public). 

In een local public folder structuur worden voornamelijk koala interface files en koala data definitie 

files, en public koala componenten beschikbaar gesteld, en in een global public folder (gpf) 

structuur een mix van sources en derived files. Er kunnen mogelijk koala interfaces in staan maar 

zeker ook COM en idl elementen. Bij derived files in een global public folder moet men denken aan 

gegenereerde proxy/stub/guid source modules, en gegenereerde header files. Zo'n global public 

folder moet ook gebruikt worden buiten de build tree waarin hij staat, er zijn dan ook verwijzingen 

vanuit andere build trees naar de global public folder. 

Voor Climbexion betekent dit dat er een element bijkomt: de soft-link van een build tree naar een 

Pagina: 146 / 230 

Build forest




global public folder in een andere build tree. Strikt genomen is dit niet nodig omdat de koala pd 

files zo'n tree kunnen definiëren. Maar ik zag dat ze hiervoor Windows shortcuts te gebruiken. 

Er zijn twee smaken: de soft-link naar een folder binnen het package, en de soft-link naar een folder 

in een ander package. Het tweede type hoeft niet per se opgelost te worden. Net als package 

references trouwens. In export en import drawers komt immers geen volledige tree voor. 

Het gebruik van import limitations op satellites en info-trees kan gebruikt worden om een aantal 

build trees te trimmen zodat daarin alleen de global public folders en de executables beschikbaar 

worden gesteld. De subtrees met eigen packages bevatten natuurlijk wel alle sources, om de eigen 

executable te maken. Om dergelijke import limitations te kunnen gebruiken zal de executable, de 

target van de build waarschijnlijk gescheiden van de intermediate result files en de buildgraph 

worden bewaard. 

Normaal mag een team slechts eigen packages wijzigen. Packages van andere teams worden 

normaal alleen gewijzigd met patches. (je kunt wel files wijzigen in info-trees en working-trees, en 

misschien satellites maar niet en in de center-drawer, want de version pool is read-only voor 

normale transfers). Nu Climbexion faciliteiten biedt om build resultaten op te slaan wil je dat niet 

prijsgeven als het build forest geïntroduceerd wordt. Maar als build folders verspreid in packages 

staan, dan zou hun inhoud ook gewijzigd moeten kunnen worden door andere teams, bijvoorbeeld 

tijdens hun dagelijkse build, bijvoorbeeld als de build een “clean build” is, waarbij h files proxies, 

stubs en guids c files worden gegenereerd. Dus deze derived elements mogen vrij worden 

gewijzigd. Deze files zullen daarom misschien in een andere pool, met andere access rechten 

moeten komen. 

Pagina: 147 / 230 

global public reference structuur




Het lijkt er op dat soft-links het best gespecificeerd kunnen worden in een global public folder van 

een aan het masterproject gerelateerd package. Ze staan dan met z'n allen centraal in een lijstje, en 

hoeven alleen daar te worden bijgehouden. Er is dan wel een mechanisme nodig in de build tools, 

om ook de global public folders van de eigen tree via die soft-link te benaderen en niet rechtstreeks, 

dan wel dat ze juist niet via soft-links benaderd worden, maar wel rechtstreeks, maar in ieder geval 

niet dubbel. Hopelijk is dit verder oplosbaar zonder bijdrage van Climbexion. Climbexion zou 

mogelijk slechts moeten bewaken dat soft-links niet buiten de working-tree of de info-tree 

verwijzen. 

Het kan voorkomen dat de ene televisie een tuner gebruikt van Fabrikant A, met een driver in 

package TunerA, en de andere televisie een tuner van Fabrikant B met de driver in TunerB. Beiden 

implementeren interfaces uit de UHAPI standaard. De middleware moet dus de ene keer zijn 

referentie gegevens inlijven uit de global public folder van TunerA, en de andere keer uit de global 

public folder van TunerB, vaak afhankelijk van het project, en soms afhankelijk van diversity 

binnen het project. In het laatste geval moet de build procedure de juiste soft-link kiezen, 

afhankelijk van build parameters. 

Waarom wordt dit niet opgelost met louter Koala component structuren? Ik denk dat deze methode 

een redelijk overzichtelijke structuur is, voor ieder die aan de software werkt. De structuren van de 

pd files zijn normaal niet zichtbaar voor iemand die met de file browser door de tree gaat. Normaal 

werk je aan de sources voor één executable tegelijk. Die staan dan in een subtree. 

Waarom kan dit beter opgelost worden met pd files? Wat in deze structuur niet kan is een package 

met onderdelen voor de ene executable en met onderdelen voor de andere. Een package kan zich 

slechts in één tree tegelijk ophouden. Dit is een extra eis aan een package. Normaal is een package 

een eenheid van distributie en beheer, een extra eis kan betekenen dat een package opgesplitst moet 

worden. Als je dit met pd files regelt, om opsplitsing te voorkomen, dan kan een package zelf 

mogelijk zo gestructureerd worden, dat er meerdere pd files in voorkomen. Er is dan verschil tussen 

een Climbexion package en een Koala package. Een Climbexion top folder van package Pa0 zou 

dan kunnen bestaan uit de folders: Pa0-computer-1, Pa0-computer-2, Pa0-common, Pa0-gpf. 

2.6.4 Build bij NXP 

Koala als make tool 

De cd files van Koala bevatten voor iedere c file (bijvoorbeeld foo.c) een module clausule, (de 

clausule foo). Zo'n clausule is de entiteit die vertaald moet worden in een h file (foo.h), waarbij 

gegevens uit gerefereerde id files en dd files worden bewerkt en ingelijfd in de h file. De buildgraph 

daarvoor wordt geconstrueerd tijdens uitvoering van het engine dat in de Koala documentatie is 

beschreven. Het genereren vindt meen ik plaats onder de eigen besturing van Koala, dus niet met 

behulp van een make tool. De folder met header files (één per nodige module) die Koala bijhoudt 

zijn daarna de de basis van de buildgraph. 

Test harness generator 

Voor het audio/video platform wordt een aparte executable gemaakt, om dit platform te testen. De 

methods van de UHAPI interfaces kunnen in deze executable rechtstreeks aangeroepen worden met 

behulp van een menu en de remote control. Ook kunnen de interfaces gebruikt worden in testscripts 

Pagina: 148 / 230




via een RPC methode tussen een desktopcomputer en een televisie, waarbij het script verwerkt 

wordt door een tool op de desktop. Het test-harness bestaat uit software voor menu en remote 

control enerzijds en voor communicatie met een testscript op de PC anderzijds, en wordt voor een 

belangrijk deel automatisch gegenereerd. 

De test harness generator van het platform onderhoudt veel menu files, en veel header en c files. De 

cd file van het harness moet afgestemd blijven met de cd file van het platform. Allen moeten ook 

nog eens afgestemd blijven en met een aantal id en dd files. Een aantal interfaces van het platform 

worden niet bediend door het harness, zoals bijvoorbeeld de pump en pump engine interfaces. Die 

worden door de harness component doorgegeven naar de top cd file. 

Misschien is de generator lastig te combineren met Koala, en is hij daarom buiten de build 

procedure gebleven. Mogelijk speelt ook mee, dat de repository (Synergy) vooral voor sources is 

bestemd, dus niet voor de files die uit een reguliere build komen, en is er daarom niet gezocht naar 

een methode om de generator in de build procedures te krijgen. Dus moeten de ontwikkelaars zelf 

het test-harness genereren als dat nodig is en daarna het nieuwe harness overdragen aan de teamdrawer. 

Hier gaan dingen fout als in latere project stadia vooral met product software getest wordt. 

De ervaring leert dan ook dat het zinvol is om dergelijke generatoren koste wat het kost in de 

reguliere build procedures in te bouwen, en het gegenereerde te beschouwen als derived files. Als 

het genereren nagelaten wordt leidt dat vaak niet meteen tot compilatie fouten, maar wel tot 

moeilijk te determineren fouten op run tijd. Een opmerkelijk fenomeen doet zich hierbij voor: als 

een ontwikkelaar tegen het probleem aanloopt is het vaak de eerste keer dat die ertegenaan loopt en 

dus zoekt hij zich wezenloos. De fout staat maar zelden vooraan in de persoonlijke checklist van de 

fout zoekende programmeur. Maar toch: velen hebben ooit zo'n probleem opgelost. 

Iets anders dat mis gaat met de test-harness generator is de “vertaling” van constanten. Ik bedoel 

hiermee symbolen die in een nummer vertaald worden door de compiler. Toen ik NXP verliet was 

dit probleem nog niet opgelost. Het tool dat de testscripts afhandelt gebruikt een andere notatie 

wijze van de declaratie van deze symbolen dan wat geleverd wordt door de generator. Dit heeft 

geleid tot een dubbele registratie van de constanten: zowel in de data definitie files van Koala als in 

aparte tekst files voor het test tool. Ook zo'n dubbele administratie is niet aan te bevelen, en een 

bron van fouten. 

Er zijn nog enkele van dergelijke generatoren in gebruik, maar daarmee heb ik niet of nauwelijks te 

maken gehad, dus die blijven hier onbeschreven. 

2.6.5 Versnipperingen 

Meerdere buildgraphs en build scripts 

Hoewel de binnen NXP gebruikte (recent timestamp) make methode toestaat dat er één build script 

wordt gebruikt voor alle targets, is dit niet de werkwijze binnen NXP. Er is gescheiden beheer van 

build scripts, gewoon omdat degene die verantwoordelijk is voor een product build niet 

verantwoordelijk is voor een platform build, en de beheerder van een unit-test build weer een ander 

kan zijn. De build scripts bevatten de duiding van het target, de cross-compiler/linker en overige 

Pagina: 149 / 230




generator referenties, en de top cd file. 

Dank zij KOALA is er weinig reuse van intermediate results, zoals object files. Dus kan elke 

buildgraph zijn eigen build folder hebben. Er is één script per target met opties als debug, assert, 

optimize en dergelijke, die ieder hun eigen folder krijgen. Per folder wordt er één make file 

(buildgraph) gemaakt. 

Binnen een buildgraph zijn er subgraphs voor speciale doeleinden, bijvoorbeeld om een build vanaf 

scratch uit te voeren. Dit vind je ook terug in de build scripts. 

Nu er gebruik wordt gemaakt van “COM” is er een hoeveelheid shared intermediate result files. De 

structuur is navenant: 

● Er is een gemeenschappelijke “general” folder met een gegenereerde make file waarin de 

buildgraph voor de general derived file wordt beschreven. 

Er is een build folder voor elke target. Waarin de make file wordt geplaatst die de buildgraph van 

de target beschrijft, en een script dat eerst de “general” build uitvoert en dan de eigen build. 

Ontwikkelingsgang 

Oorspronkelijk in de Tv software werd er één build folder (met een inner-reach structuur) gebruikt. 

Dat wil zeggen één voor iedere executable: “debug” executable en “optimize” executable hadden 

ieder hun eigen build folder. 

Met de komst van Koala kwam een test harnas voor het AV platform in een andere build folder dan 

een test harnas voor Middleware. Deze build folders stonden en staan in de top folder van de tree. 

Deze indeling is er nog steeds, maar om een aantal redenen zijn een aantal derived files in een eigen 

folder terecht gekomen. 

● Toen Philips SC dedicated chips ging maken voor televisies kwam een deel van de software 

ontwikkeling voor rekening van SC en een deel maakte de klant, en kwamen er export 

limitations. Oorspronkelijk gebeurde dit doordat object files uit de build folder werden 

geselecteerd, en in een statische library werden geplaatst, die zelf in een folder van het 

betreffende package stond. (één voor testen: (assert, logging, debugging), één voor 

optimize). Dit gebeurde dus met een extra kopieerslag. 

● Toen kwam KOALA waardoor dit moeilijker was. Immers, door de compile time binding 

van KOALA is de objectcode van een module in executable A anders dan de objectcode in 

executable B. Bij software voor de MIPS zag men de constructie dat een static object library 

ingebed werd in een KOALA component, die de interfaces naar die library verzorgde. Voor 

de TriMedia werden executables beschikbaar gesteld. In beide gevallen één voor optimize 

en één voor het testen. 

● Met de introductie van de “com” component methode kwam er in de top van de tree een 

folder voor gegenereerde header, stub, en proxy files. 

● Met de introductie van het build forest gaan deze gegenereerde header en c files in de global 

public folder komen, waarin ze thuishoren. 

● Nu, met het build forest, wordt het weer eenvoudig mogelijk om binary code per package te 

distribueren. Echter de oude situatie waarin gegevens gekopieerd werden uit de build folder 

in een repository folder lijkt achterhaald. De gegenereerde code kan beter door de build 

procedures meteen in de juiste folder in het package geplaatst worden zodat er een uniforme 

Pagina: 150 / 230




manier van werken is voor de builds in import/export gelimiteerde en in de ongelimiteerde 

omgeving; voor de producent van het package en voor de consument. De uniforme methode 

betreft zowel de builds van binaries, als ook de packaging die nodig is om een werkend 

systeem te onderhouden in de televisie. De build folders in de top van de tree zullen geheel 

verdwijnen. 

● Vermoedelijk wordt Koala op termijn opgevolgd door een methode die wat minder uitgaat 

van de “resource restricted” aard van een televisie en de daarvan profiterende compile time 

oplossingen: er is misschien wel genoeg geheugen en genoeg processing power voor 

runtime oplossingen, en het overslaan van code kan desnoods zelfs plaatsvinden in 

installatie procedures. (In software kun je nu eenmaal alles van hot naar haar verhuizen.) 

Dan ontstaat een systeem waarin diverse targets diverse object files en diverse header files 

kunnen delen, Voorlopig heb ik hiermee geen rekening gehouden. In de hele elektronica 

branch zal de software wel variëren van uiterst resource restricted systems, to zeer resource 

rich systems. 

● Import/Export limitations dragen ook bij aan de versnipperingen omdat het target van een 

build gescheiden wordt van de intermediate result files. De targets zijn de (dynamic link) 

libraries of de executables. Zij worden altijd beschikbaar gesteld. De intermediate result files 

zijn bijvoorbeeld de object files en de door KOALA gegenereerde header files. Deze laatsten 

worden mogelijk niet beschikbaar gesteld aan derden, of ze worden toch niet gebruikt door 

degenen die het target niet zelf willen genereren. 

● Naast Philips CE worden de chips verkocht aan een groot aantal afnemers. Geen van die 

afnemers werkt met KOALA, dus dat is een interne aangelegenheid van NXP, in haar deel 

van de software. Daardoor is het leveren van gegenereerde code onvermijdelijk: de klant 

beschikt niet over de Koala generatoren. 

● Sommige klanten werken met de volgende procedure om een compleet product samen te 

stellen: source code, static libraries, dynamic libraries en executables worden opgestuurd 

naar de klant, en die maakt er een product package van dat wordt teruggestuurd. Dit is een 

no-nonsense procedure: je levert naast libraries natuurlijk geen source code die toch niet 

gebruikt wordt voor het samenstellen van het product. Deze methode is een combinatie van 

import en export limitations. Het is niet bepaald een optimale methode voor een 

gemeenschappelijk project. 

De bedoeling van Climbexion is dat deze wijze van werken vervangen wordt door methoden 

waarbij ieder optimaal kan beschikken over source informatie, en zelf de binaries kan 

genereren waarin de eigen software is ingebed. 

Deze klanten eisen dat de software kwaliteit die NXP levert aan het begin van de 

samenwerking hoger is, dan wat NXP/Philips CE gewend zijn. Dat is natuurlijk niet zonder 

reden: nu de import/export limitations tot het uiterste worden doorgevoerd is het lokaliseren 

of toewijzen van een bug geen peulenschilletje. 

Bij NXP zeggen ze: wij passen ons aan aan de Aziatische manier van zaken doen. Ik 

verwacht en ik hoop dat deze kwaliteit verbetering lukt zonder het idee van gezamenlijke 

chip en software ontwikkeling geweld aan te doen. Het is natuurlijk niet de bedoeling dat 

gewacht wordt tot het reference model van NXP helemaal volmaakt klaar is voordat de 

eerste grote klant instapt. Daarvoor heb ik mijn repository niet Climbexion genoemd. En 

Pagina: 151 / 230




bovendien is internationaal samenwerken om te ontwikkelen daarvoor veel te leuk. 

Mijn verwachting dat kwaliteit verbetering lukt is hierop gebaseerd: NXP “leunde” soms 

wat te veel op acceptatie tests van CE, om daarna met verve de daaruit voortvloeiende 

problemen op te lossen. Die tests hadden ze zelf kunnen doen: acceptatie tests horen een 

formaliteit te zijn. Je klanten horen jou niet te vertellen wat de status is van je product, maar 

jij hoort je klanten te vertellen wat de status is van je product. 

De invloed op builds 

De versnipperingen zijn als volgt samen te vatten: Containers voor derived files bevinden zich op 

diverse plaatsen in de working-tree. 

Deze containers bevatten natuurlijk? de bijbehorende permanente dependency lists, die van hen zelf 

en die van hun content. De permanente dependency lists moet waarschijnlijk even versnipperd 

opgeslagen worden als de derived files. Veel containers kunnen waarschijnlijk daar in de workingtree 

geplaatst worden, waar er een primary source file bestaat met gegevens over die container. Op 

de plaats waar een Koala top component staat, daar zullen ook wel containers horen, maar toch 

zeker ook in global public folders. Build tools moeten de versnipperingen faciliteren. 

Als build targets en hun intermediate result files gedistribueerd worden betreft dit waarschijnlijk 

een vooraf afgesproken beperkte hoeveelheid varianten. (voor TriMedia bijvoorbeeld: assert, 

optimize). Maar voor persoonlijke opslag zouden mogelijk meerdere varianten, en gemengde 

targets gewenst kunnen zijn, dus de opslag in satellites kan complexer zijn dan de opslag in export 

drawers. Met name het activeren van logging van de inhoud van variabelen kan aanleiding zijn tot 

meer persoonlijke intermediate result files en targets. Binnen de debug containers komen dan 

objects waarin logging is geactiveerd, en mogelijk ook varianten, waarin logging niet is geactiveerd. 

2.6.6 Other-focused build results 

In een team-drawer zonder transfer-drawer waarin dagelijks build results worden opgeslagen moet 

welhaast gebruik worden gemaakt van other-focused build results. Als de clean build klaar is, kan er 

alweer een changeset zijn overgedragen, en slaat het build result niet langer op de tip van drawer. 

Gegeven de aard van een derived files: ze horen bij een tag, en zijn een vorm van informatie over de 

tag maakt dat ze “principieel” behoren tot de other-focused files. 

Een reden om build results überhaupt op te slaan in de team drawer: builds kunnen onbetrouwbaar 

zijn, zodat je regelmatig clean builds wilt uitvoeren. Dit kan efficiënt worden uitgevoerd door de 

build manager die dit periodiek doet voor het hele team. Dit argument vervalt als builds onder alle 

omstandigheden erg betrouwbaar zijn, maar spreekt weer erg aan als per work-item een satellite met 

working-tree gebruikt wordt. 

Een andere reden om other-focused files te gebruiken: een ontwikkelaar test met twee build targets, 

en controleert nog twee andere builds op foutloos resultaat, je hebt dan 4 builds gepleegd maar het 

team heeft behoefte aan de opslag van een stuk of 16 build targets. Ook hier zou de build manager 

dit geregeld kunnen doen voor het hele team. 

Build voor baselines en patches: in principe zouden build results kunnen worden overgedragen 

samen met de source files. Vanuit drawers die exclusief door een build-manager worden beheerd. 

Dus zijn other-focused files hier mogelijk vermijdbaar. 

Pagina: 152 / 230




Mogelijk wordt in de toekomst meer gewerkt met script talen zoals bijvoorbeeld Python. Die 

hoeven niet gecompileerd te worden. Of met JIT compilers die op runtime compileren, net voordat 

de module gebruikt wordt, hoewel sommige JIT compilers byte code compileren naar machine 

code. Dit vermindert mogelijk de behoefte aan builds en build results, en misschien ook de behoefte 

aan de opslag ervan in een repository. Soms kun je zulke programma's niet alleen laten 

interpreteren, maar kun je ze ook statisch compileren, om de werking te versnellen. De behoeft aan 

wel of niet other-focused build results is hier niet direct te overzien. 

Builds worden momenteel gebruikt als een soort kwaliteit borging bij overdrachten. Dit is niet 

alleen omdat mensen steken laten vallen, maar ook omdat merge programma's niet volledig zijn te 

vertrouwen. Dit gebruik is op zich geen reden om build results op te nemen. Wat je bij een 

overdracht of periodiek mogelijk hierom wilt opslaan in de repository is de boodschap van het build 

programma: “build finished with error code 0” (of niet natuurlijk). Dit is typisch informatie die in 

een een other-focused file wordt geplaatst: het vertelt iets over het snapshot. 

2.6.7 Conclusies 

Export limitations maken het noodzakelijk dat binary code wordt opgenomen in de repository, 

verschillen in “software engineering practices” tussen de teams noodzaken soms tot de opslag van 

build results, ook import limitations maken het soms wenselijk. Efficiency op de “werkvloer” kan 

aanleiding zijn om build results op te nemen in de repository. 

Als je binaries opneemt in Climbexion dan lijkt een build methode gebaseerd op “different” 

timestamp of “content hash” onvermijdelijk, en alleen al door het gebruik van een repository is deze 

methode te verkiezen boven de “recent” timestamp methode, zelfs als je de build results niet 

opslaat. Als je build results via de repository beschikbaar wilt stellen, dan is het absoluut 

noodzakelijk. 

Het gegeven dat distributies plaatsvinden per package betekent dat te distribueren build folders met 

hun inhoud worden opgeslagen bij die packages, misschien als tarball, liefst als een verzameling 

first class citizens. Build targets moeten in ieder geval als first class citizens behandeld worden in 

verband met de limitations. 

We wisten reeds: build managers kunnen langdurig builds uitvoeren, zonder team-drawer en/of 

transfer-drawer langdurig te blokkeren voor wijzigingen: door build resultaten op te nemen in owndrawer-focused 

files. 

2.6.8 Build extra's. DianPush Build 

Gatherers en Outliners 

Probleem: 

1. Een beetje intelligente linker geef je een start module, en je wijst hem een verzameling met 

object-files. De linker zoekt bij external references, die modules die de externals bevatten. 

Dit gebeurt met een verzamel algoritme of gatherer. Na het linken is bekend welke modules 

ingelijfd zijn, en daarmee is de dependency list bekend, en kun je vaststellen of er gelinkt 

had moeten worden. 

2. Een compiler geef je een source module en wijst hem een verzameling met import files. De 

Pagina: 153 / 230




compiler lijft dankzij de referenties in de code de betreffende import files in. Dit gebeurt met 

een andere soort gatherer. Na het compileren is de dependency list bekend en kun je 

vaststellen of er opnieuw gecompileerd had moeten worden. 

Gatherer type één. Linkers kunnen dit op libraries. De link-editor op IBM mainframes had zo'n 

algoritme. Het werd daar altijd toegepast omdat een object file altijd in library terecht kwam. 

Op de Microsoft en Unix systemen waarop ik sinds de jaren tachtig actief ben worden libraries 

vooral toegepast voor standaard software libraries, en minder voor de software die men zelf 

onderhanden heeft. Daar verzamelt de linker niet wat hij nodig heeft uit het aanbod, maar lijft hij 

alles in dat aangeboden wordt, met uitzondering van datgene dat in de standaard libraries staat want 

daarvoor gebruikt hij de gatherer. 

De eerste gatherer eist dat zijn input pool in zijn geheel op orde is: alle bekende primary sources 

moeten zijn gecompileerd tot objects. Immers een unresolved reference vertelt niet in welke file de 

betreffende external wordt verwacht, dus make weet niet welke file gemaakt moet worden. Om de 

pool op orde te krijgen kunnen eventueel script nodes buiten de subgraph van de executable 

uitgevoerd worden. 

De aard van de tweede gatherer is zo dat die weet welke file ingelijfd moet worden. Als die er niet 

is, dan kan worden nagegaan of er een subgraph bestaat met de file als target, en uiteindelijk of zo'n 

subgraph kan worden aangemaakt, als die nog niet bestaat. 

Kun je met gatherers een buildgraph maken door gebruik te maken van uitgeklede linkers en 

compilers die de gatherer bevatten, en die vooraf werken? Dan is er, in ieder geval voor het 

verzamel algoritme van de linker het probleem die pas kan worden uitgevoerd als de objects er zijn, 

zelfs als het een verzamel algoritme type twee zou zijn. Hoe vooraf is dat nog? Voorlopig zoeken 

we een oplossing zonder vooraf de graph te maken. 

Wat een voorwaarde is voor de different timestamp methode, namelijk de permanente opslag van de 

timestamp van een file, is tevens een optimalisatie van het automatische generatie proces. Er wordt 

gebruik gemaakt van de dependency lists van de vorige keer, en alleen die dependency lists met hun 

subgraphs worden bijgewerkt waarvan minstens één lid is gewijzigd, of verdwenen, en uiteraard 

wordt de betreffende script node uitgevoerd. 

Een dependency list die uitsluitend uit source (niet afgeleide) files kan bestaan kan worden 

geselecteerd door de gatherer en opgeslagen als output file van zijn script node. Ook het linker 

algoritme waarvoor de object library vooraf op orde moet zijn kan op die manier werken. Deze 

dependency list wordt gemaakt door het verzamel algoritme, door de gatherer, niet vooraf, maar 

tijdens het vuren van de script node en is na afloop beschikbaar voor permanente opslag, samen met 

de versie identificatie van de bijbehorende input files. 

Stel de gatherer wil files inlijven die derived zijn. De dependency list moet dan mogelijk al gaande 

worden ontwikkeld. De file die op het punt staat om ingelijfd te worden moet diep gecontroleerd 

worden op actualiteit, en misschien gegenereerd worden. De uitvoering van de script node kan pas 

verdergaan nadat controle en/of generatie klaar is. Een bezwaar tegen zo'n recursieve procedure is 

dat mogelijk niet iedere generator en niet ieder operating system faciliteiten levert om te wachten op 

een file, die mogelijk nog gemaakt moet worden. Een ander bezwaar is dat er meerdere tools 

tegelijk aan de gang zijn, die elkaar mogelijk ernstig vertragen, omdat ze allen liefst alle 

beschikbare geheugen gebruiken. Voor een simpele oplossingen zonder pipes geldt verder: van die 

generatie tools is er één aan het werk, en de anderen wachten op hem, terwijl ze hem ondertussen 

Pagina: 154 / 230




vertragen. Voorlopig noemen we dit: “the unwanted recursion” als we ernaar verwijzen. 

Soms is er een alternatief voor deze recursive procedure. De oplossing die ik ken is een push 

methode. Na afloop zijn alle targets up-to-date. Dit is bijvoorbeeld mogelijk onder de volgende 

condities: 

1. Elke generatie tool werkt met een primary input. 

2. De primary input van een generatie tool moet als zodanig herkenbaar zijn, Bijvoorbeeld, een 

tool dat slechts nodig is voor twee van de tien c files gebruikt niet de parameters uit het 

script, maar leest een parameter file als primary input. De c files zijn dan voor hem geen 

primary input, maar de speciaal getypeerde parameter files wel. 

3. Voorlopig eisen we dat primary input files altijd source of derived files zijn, zodat er voor 

iedere script node een primary input file bestaat, zelfs als deze leeg is, of als zijn inhoud op 

de een of andere manier verondersteld kan worden. Andere oplossingen dan met een primary 

file beschouwen we voorlopig als frivool, en goed voor later. Nu gaat het om een rigide 

systeem. Waarschijnlijk is rigide hier beter dan frivool. Ook voor secondaire data zoals 

opties prefereren we trouwens een input file boven environment variables, zodat een 

verandering opgemerkt wordt. 

4. Je moet een generatie volgorde kunnen aanwijzen: bijvoorbeeld je wilt eerst alle idl 

compilaties uitvoeren, dan koala, dan c compilaties, dan zo nodig object libraries bijwerken, 

tenslotte de te vernieuwen executables maken. Kortom er is een categorie indeling van de 

generatie tools, en er is een volgorde waarin de categorieën afgehandeld worden. Zo'n 

categorie zullen we een push-position noemen. 

De eerste drie condities zijn natuurlijk ook heel praktisch als je met een pull algoritme zou werken. 

We zullen ze de “build preconditions” noemen. Merk op dat aan de output zijde niet geëist wordt 

dat er een output file gemaakt wordt met dezelfde name als primary input file. De opgeslagen 

dependency list is natuurlijk wel een file die dezelfde name krijgt als de primary input file. 

Push make op een volledige working-tree is vermoedelijk een make procedure die je het bloed 

onder de nagels vandaan kan halen door alle extra werk die hij verricht voor hij de ene executable 

levert die je nodig hebt. Aan de andere kant is dit toch wel de natuurlijke methode als je gebruik 

wilt maken van de dependency lists van de vorige keer: de nieuwe list is een output file van de 

gatherer, en is beschikbaar na afloop van het script van de node en kan dan voorzien worden van de 

version metadata van de input. 

Stel je hebt een folder voor derived files voor zowel een product target, een platform target en enige 

targets voor unit tests. We gebruiken een c compiler, een library tool en een linker. Als je een 

product target wil maken dan is de target selectie best wel mogelijk: er is een primary source file 

voor ieder target. Het push algoritme slaat dan de primary source files voor de andere targets over. 

Iets soortgelijks kan vervolgens gelden voor libraries. En tenslotte selecteert een product build de c 

source files van de working-tree, minus de c files voor tools, en minus de c files voor test harnesses 

enzovoort. Ook deze selectie lijkt niet te moeilijk. Een unit test gebruikt de c file sources uit zijn 

harness folder en de modules van een paar componenten. Het platform target gebruikt de c files van 

zijn harness folder, plus de c files in de platform subtree minus folders voor tools en test harnesses. 

Folders voor harnesses gebruiken mogelijk soft-links naar extra resources. Expliciete subtree 

selectie in de working-tree, en subtree duiding door folder entity type selectie of exclusie lijken 

redelijk stabiel, en niet erg onderhoud gevoelig. Ze zouden simpel en overzichtelijk moeten zijn. 

Maar anderzijds: de NHSW tree bevat een allegaartje aan folder entity typen, en is een integratie 

van allerlei substructuren, er is legacy. Simpel, overzichtelijk, betrouwbaar, en stabiel is niet 

Pagina: 155 / 230




gegarandeerd. 

Expressies voor afbakening van de input zouden voor targets en intermediate result files kunnen 

worden vastgelegd. We noemen de software die tijdens build een afbakening beschikbaar stelt een 

outliner. Die software zou dus van de expressies gebruik kunnen maken. We blijven rigide: een 

outliner die een outline beschikbaar stelt doet dat voorlopig in de vorm van een index met de 

resource locator's van files. 

Outliners kun je gebruiken als gatherers ontbreken, of nog niet bruikbaar zijn. Ze worden gebruikt 

in push methoden voor primary source selectie uit de working-tree, en sturen ook die pull 

methoden, waarvan de primary source selectie volledig vooraf wordt geconstrueerd. 

Voor een pull methode kan de buildgraph als volgt gemaakt worden. De outliner van de linker weet 

waar in de working-tree de primary source files van zijn libraries staan, maakt er een lijst van, en 

vertaalt de source namen in library namen. De outliner van een library weet waar zijn c files staan 

en vertaalt de namen van de c files in namen van de object modules. De vertaalde namen vormen de 

dependency list voor de script node die de library aanvult, of de linker creëert. 

Bij een push methode wordt eerst een outline gemaakt van alle betrokken c files. Als de object files 

gemaakt zijn, wordt een object outline gemaakt voor de eerste library en wordt die bijgewerkt. Zo 

worden ze successievelijk bijgewerkt. Tenslotte wordt de outline van libraries voor de linker 

vastgesteld en wordt die uitgevoerd. 

In het algemeen lijkt de push methode de voorkeur te hebben boven pull, immers in de build sessie 

hoeven de script nodes dan niet in een graph structuur te worden gezet, maar in simpeler 

gesorteerde lijst (precondition 4) Bij een pull methode moeten de outlines van te voren beschikbaar 

zijn, maar bij een push methode hoeft een outline pas beschikbaar te zijn als je aan een pushposition 

begint. Er kan gebruik worden gemaakt van derived files die wel of niet zijn ontstaan in 

voorgaande push-positions. 

Kun je gatherers gebruiken als outliners? 

De primary file waarop de gatherer wordt losgelaten in fase één van de build moet up-to-date zijn, 

dus een source file zijn. Je moet de gatherer dus vooraf gebruiken. Dan geldt voor een aantal 

references misschien dat ze unresolved zijn, en van een aantal dat ze derived files zijn. Een garantie 

zou moeten zijn dat de dependency list compleet is, dus liefst geen references of altijd dezelfde in 

de derived files. Verder geldt voor iedere derived file dat de primary input name moet zijn af te 

leiden uit de file name. Deze primary input file en de erbij behorende outline zijn zijn dependency 

list. In de (rigide) beschrijving van DianPush ga ik er vanuit dat er geen gatherers gebruikt worden. 

In feite ga ik ervan uit dat het afgebakende deel van de working-tree niet top-down tot stand hoeft te 

komen. 

In de working-tree worden outliners gebruikt om een build zoveel mogelijk te beperken tot de 

essentiële primary input files, en om restricties op te leggen aan de plaatsen waar de gatherer mag 

zoeken naar secondary input files. NHSW kent secondary input files die alleen binnen een 

component of binnen een package gebruikt mogen worden. Een outliner kan dit faciliteren en zo 

bijdragen aan de integriteit en onderhoudbaarheid van de software. Als je zondigt en ten onrechte 

zo'n file wilt inlijven dan heeft dat een error tot gevolg: hij behoort immers niet tot de outline. 

Compilers en linkers zijn typisch entiteiten die gebaat zijn met een gatherer. Normaliter is die 

ingebouwd. Folders en libraries voor derived files zijn typisch entiteiten die een outliner gebruiken 

Pagina: 156 / 230




die in zijn geheel ingelijfd wordt. Gathering voor een linker wordt vaak vermeden met zeer 

nauwkeurige outliners. 

Overall outliner. Inleiding 

Koala is een gatherer om een outline te maken. De component description files (cd-files) bevatten 

een lijstje met in te lijven componenten en een lijstje van modules die bij de component horen. Voor 

ieder target is er een top cd-file. De begrenzing van Koala is de working-tree. De begrenzing van de 

verzameling waaruit de linker de objects verzameld voor het target: die lijst met modules wordt 

door Koala samengesteld door een componenten tree op te zetten. Koala gebruikt elementen uit het 

working-tree landschap om de componenten tree te trimmen en om modules te selecteren: met 

name pd files, id files dd files. Ook gegevens in de cd files worden bij het trimmen gebruikt. De cd 

files hebben een aantal c files uit hun directe omgeving onder hun hoede en staan in contact met een 

aantal andere cd files en bij een build word een subgraph samengesteld van de cd files. 

Ik heb niet veel werk verricht voor de TriMedia's. De programmeurs daar gebruikten recursive 

make, maar waren blij dat ze er dankzij Koala vanaf konden komen. Als ik hun gemopper goed 

begrepen heb: ze hadden het pull algoritme vervangen door een ander recursief algoritme. Daardoor 

werd er wel eens gevuurd voordat de files uit de dependency list up-to-date waren. Met Google 

vindt je er talloze beschrijvingen en voorbeelden van. Trouwens je vindt dan ook veel commentaar 

op recursive make, maar ook regels om het goed te doen. Ik denk dat ze recursive make vooral 

gebruikten vanwege het feit dat iedere make file een aantal sources onder zijn hoede heeft en en in 

verbinding staat met andere make files. 

Waarschijnlijk komen er of zijn er meer verzamelende outliners, dan Koala. Die verzorgen de 

afbakening van waarschijnlijk alle script nodes. We zullen zo'n outliner een custodian outliner 

noemen. Maar in het vervolg, als we spreken we over “de outliner” dan bedoelen we de custodian 

outliner. Omdat de component descriptor file reeds voorkomt bij Koala zullen we spreken over een 

custodian file . Een custodian heeft in zijn directe omgeving een aantal source files onder zijn hoede 

en staat in verbinding met enkele andere custodians. Onder zijn hoede hebben of hoede zelf zullen 

we vertalen als “notice”. Onder “zijn hoede” zal ik noteren als “in notice” Custodian is toch wel een 

mondvol. We zullen dit afkorten tot dian. 

Voorlopig ben ik rigide en plaats naast iedere cd file van Koala een dian file, Daarnaast komen er 

nog dian files die folders voor h , id, dd, idl files in de gaten houden, buiten de componenten. En 

tenslotte zijn er de dian files met de folders voor derived files in notice. Waar Koala zelf zijn 

outlines bepaalt is dat natuurlijk overbodig, maar ik wil toch wel een indruk krijgen voor wat betreft 

de feasibility van dians. Als je naar een cd tree kijkt, dan kan een component er meermalen in 

voorkomen. Eigenlijk is dat een vorm van node splitsten. De graph structuur is een DAG. Het lijkt 

logisch om een DAG toe te staan voor dians. De outliner kan daarmee rekenen: indien bij het 

bepalen van een outline een dian andermaal bezocht zou worden, dan wordt hij overgeslagen. 

Als een build start is de parameter die je aan de outliner geeft: een start dian. Je vraagt de outliner 

om een build outline te maken: wat de outliner retourneert: een index van dians die bij de build 

betrokken zijn. De index wordt mogelijk intern in de outliner gebruikt. Alle bij de build betrokken 

primary source inputs horen bij één van de dians in de outline. Ook primary derived inputs vallen 

binnen de dians, maar die staan nog niet vast. Ze kunnen immers voor een deel gegenereerd worden 

als het push algoritme aan de gang gaat. Zelfs, zoals we nog zullen zien, kunnen ze gaande de build 

Pagina: 157 / 230




vervallen. Een positie in een normale outline van een dian outliner bevat (voorlopig) de fully 

qualified name van de dian, en een local name van de file. Er komt een moment dat een file of een 

outline nodig blijkt als input voor een tool, dan moet het paar (dian,file) alsnog worden vervangen 

door de fully qualified name van de file. 

Voorbeelden van requests aan de outliner: 

Gegeven Request Resultaat 

Dian: /nhsw/product/target.dian Dians outline Index of dians 

Folder: objects 

Dian: /nhsw/platform/derived/object.dian 

File: m3.c, 

Dian: /nhsw/platform/tuner.dian 

File: m3.c, 


Folder: object, 

Dian: /nhsw/platform/derived/object.dian 

File: m3.c, 


De Stored Input Output File (sio file) 

Primary inputs outline: 

type: c files 

Secondary inputs outline: 

type: h files 

Folder to store derived output: 

type: obj files 

Is file in primary source 

outline of folder? 

Index of c files 

Index of h files 

Index with 1 folder 

De dependency list met version informatie van de betrokken input, samen met de lijst gegenereerde 

output files worden opgeslagen in een sio file. Ook de version informatie van die files wordt 

opgeslagen. Wijzigingen in de working-tree, waardoor input files ontbreken of opschoning acties 

waardoor output files ontbreken, of corruptie als een output file is gemaakt door ongeldig handelen 

zijn hiermee te corrigeren. Namelijk door de script node te laten vuren. Omdat we met een rigide 

systeem werken zijn alle ins en outs van een script node files met version data. Hier kunnen we 

misschien maar beter niet frivool worden. 

Het is denkbaar dat een generatie tool de secondary input file “foo” inlijft als die er is, maar als 

“foo” ontbreekt dan wordt net zo goed output geproduceerd. In dat geval verwachten we in de sio 

file in de output list de regel “foo” ontbreekt. 

Derived Folders 

Folders voor derived files hebben een primary source input. Deze primary input files zijn zelf nooit 

derived omdat ze in de allereerste push-position in het build process worden gecompileerd tot 

folders. De df file geeft informatie over de derived folders die samen met hem in een gewone folder 

staan. Een van die folders is de sio folder. In plaats van een folder voor object files, zou een library 

gespecificeerd kunnen worden. 

We noemende de primary input file een df file. In de file staat een push-position (het volgnummer 

voor de push volgorde). De generatie tools die horen bij die push-position schrijven hun output en 

hun sio file in de folders die in de df file genoemd worden. Er is altijd een sio folder. Die bevat 

uitsluitend sio files. 

Pagina: 158 / 230 

yes




Waar wordt de sio file van de df file opgeborgen? In dezelfde folder als de df file of in een 

verzamel folder van het package. Het besluit daarover moet nog genomen worden. 

De dian die de df file in notice heeft, heeft ook de inhoud van de derived folders in notice. 

Op deze manier worden de versnipperingen bedient. 

Varianten 

Stel je hebt een script node en je doet één van de builds en de script node heeft als source input: 

foo versie A 

De dag erna doe je één van de andere builds, en nu is de source input 

foo versie B 

Dan is het de vraag: heb je hier te maken met een opvolger, of met een alternatief. Als geen van de 

sources gewijzigd is dan heb je zeker te maken met een alternatief. Die moet zijn ontstaan omdat de 

outliner de tweede keer een andere input koos, dan de eerste keer. Als dit onopzettelijk is gebeurt 

dan is het waarschijnlijk een fout, waarbij builds elkaar tegenwerken en waarbij de nieuwe output 

de vorige vervangt en opvolgt. Dit gebeurt keer keer als de verschillende build elkaar opvolgen. 

Varianten ontstaan niet spontaan in ons systeem. Spontane varianten zijn fouten. Wij werken met 

opzettelijke varianten. Stel we hebben besloten: 

● compiler_level {debug, assert, optimize} 

● computer {Mips, TriMedia, IntelP50} (Dit zorgt ervoor dat de juiste cross 

compilers gebruikt worden) 

“Compiler_level” noemen we het variant type, “debug” noemen we de variant. Files die 

alternatieven van elkaar zijn behoren tot verschillende varianten of variant combinaties. 

Rigide als we zijn slaan we varianten als volgt op: Waar tot nu toe een file staat in de working-tree 

daar staat vanaf nu een gelijknamige folder. In die folder bevinden zich de files. 

Een file die altijd bruikbaar is heet “...\file\{,}” 

Een file in debug mode voor IntelP50 heet ...\executable\“{debug,IntelP50}” 

Een file kan dus heten: ...\module.o\”{assert, Mips}” 

of ...\global\compiler-options.txt\{optimize,} 

of ...\tools\linker\{,TriMedia} 

Bij een build wordt een file opgegeven met de varianten die gelden voor de build: de varianten file. 

In frivole systems hebben variant combinaties vriendelijke namen en worden ze op een andere 

plaats in de path-name van een file geplaatst, bijvoorbeeld: {,} verdwijnt, "{optimize,}" wordt 

optimize\, "{assert, Mips}" wordt assertMips\ en zo. De variant combinaties komen dan 

bijvoorbeeld vlak voor de file name ...\tools\TriMedia\compiler. Ook zie je wel dat varianten deel 

uitmaken van de file name, bijvoorbeeld in source files: ...\global\compiler-options-optimize.txt. 

Als een bepaalde input van een script node zoals een c compiler de varianten file inlijft, dan begint 

het ermee dat die de varianten selecteert die van toepassing zijn De betrokken de output files zijn 

varianten met de juiste variant combinatie in hun naam, en de gatherer selecteert de input files met 

de juiste variant combinatie. Vaak is dit slechts een deel van alle varianten. Een c file is geen debug 

of intelP50 variant, de option file voor een compiler heeft alternatieven dankzij het compiler-level 

type. De (cross-) compiler is een alternatief dankzij het computer type. De object file heeft 

alternatieven dankzij een combinatie van varianten. 

Pagina: 159 / 230




Enige overwegingen. 

Een Koala package moet waarschijnlijk verteld worden wat de computer is, want dit beïnvloedt 

mogelijk de diversity. Misschien maakt het voor het package niet uit of optimize of debug gekozen 

is, en is dat irrelevante variant data. Computer data kan belangrijk zijn voor Koala packages: het is 

een diversity parameter. De output files van Koala zijn alternatieven dankzij Computer. Een 

eigenaardigheid van een dergelijke variant is misschien wel, dat er geen executables zijn die elkaars 

alternatief zijn in de projects waarin in actief was:, een TriMedia oplossing hoeft nooit op de Mips 

te draaien en omgekeerd. Voor Koala geldt misschien daarom ook dat gegenereerde files en object 

files niet als alternatieven van elkaar behandeld hoeven te worden, want die komen zo wie zo al in 

verschillende folders. 

We zouden mogelijk "target system"als variant type kunnen opvoeren. Bijvoorbeeld In het master 

project maken we software voor een Noord Amerikaanse, een Zuid Amerikaanse, en een 

Euraziatische televisie. Een team dat Koala niet gebruikt zou mogelijk als volgt kunnen werken: de 

header files waarin de diversity beschreven is zouden dan alternatieven van elkaar zijn, en de 

geproduceerde object files en executables ook. Dit variant type is van belang voor Koala packages, 

om de betreffende diversity te kiezen. De variant selecteert de diversity, De intermediate results en 

targets zijn varianten. 

Voor systemen met product families is diversity een vereiste, ook als ze Koala niet gebruiken. 

Diversity kan er soms toe leiden dat er tijdens compilatie een output file ontstaat, maar soms moet 

die juist vervallen. De preprocessor of de compiler zou dan met een geforceerde exit code moeten 

eindigen. 

Ook kan het voorkomen dat soms external functies uit een programma worden aangeroepen, en 

soms geen één, terwijl ze niet tot null zijn gereduceerd. Als je product families wilt onderhouden 

met uitsluitend compilers, library tools, en linkers, (maar wel met een dian build natuurlijk), dan 

moet je welhaast gebruik maken van object libraries, en de gatherer van de linker. 

Het zal je opgevallen zijn dat ik de dominantie van Koala over een working-tree probeer over te 

nemen met dian build, in een poging Koala te beperken tot de Koala packages. 

Het Push Algoritme 

Push gaat sequentieel door de push-positions. 

Een voorbeeld: de push-positions definiëren bijvoorbeeld de afhandeling van: 

1. controleren df files, eventueel folders maken. 

2. compileren idl files 

3. genereren test harnesses 

4. genereren Koala header files 

5. compileren Koala header files 

6. compileren van gewone c files 

7. verzamel libraries bijhouden 

8. samenstellen executables 

Push vraagt de outline (in de vorm van een index) van de sio folders van de current push-position. 

Vervolgens gaat push de index af en vraagt per sio folder de outline van de betreffende primary 

inputs en gaat die af. Alleen die primary files komen in aanmerking die behoren tot de outline van 

Pagina: 160 / 230




de dian van de derived folder, en tot de outline van de start dian. Push werkt met een merge 

algoritme, waarvan de sio files van de folder en de primary inputs van de outline de inputs zijn. 

● Een sio file zonder match wordt gecontroleerd. Zijn primaire input file moet bestaan, en 

behoren tot de volledige primary source outline van de sio folder en anders vervallen de sio 

file en de bijbehorende output files. 

● Een sio file met match wordt gecontroleerd. Alle file items in de sio file moeten kloppen met 

de werkelijkheid, anders wordt een script node opgezet en meteen afgevuurd 

● Een primary input file zonder match leidt ertoe dat de script node wordt opgezet en meteen 

afgevuurd. 

We zien hier een late vaststelling van de outlines van primary en secondary inputs. Voor software 

die deel uitmaakt van product families geldt dat veel derived input er de éne keer wel is en de 

andere keer niet of omgekeerd. Als je uitgaat van bestaande software uit een family en je maakt 

daaruit software voor een nieuw gezinslid, dan wil dat gaandeweg nog wel eens veranderen. Ook 

zullen er vaak –, dank zij de diversity –, minder derived files zijn, dan je zou verwachten als je kijkt 

naar de source files. De late vaststelling is een voordeel. Maar de late vaststelling is niet dermate 

laat, dat primary input files mogen ontstaan in de push-position waarin ze worden verwerkt, laat 

staan in eerdere push-positions. 

Het kan voorkomen dat een primary input in file twee derived folders wordt gecompileerd, het 

algoritme moet dit toelaten. Ook kan het voorkomen dat een primary source die binnen de outline 

van de start dian valt niet gebruikt wordt omdat hij buiten de outlines blijft van alle derived folders. 

Mijns inziens is een warning hier op zijn plaats. 

De object files van global public folders 

Normaal met het importeren van secondary input files wordt een ruime outline gebruikt en een 

gatherer die de selectie uit het aanbod verzorgt. Dit is vaak ook de build outline voor gpf files. 

Normaal horen alle idl files in gpf folders, samen met hun derived files. Nu deze files gebruikt 

worden in meerdere executables, ligt het voor de hand om dynamic shared libraries te gebruiken 

voor de opslag van object files. 

We willen natuurlijk geen object files opnemen die helemaal niet gebruikt worden, dat bezet maar 

flash en main memory op het target system. Nu zijn er onder Linux twee manieren om shared 

libraries te gebruiken: dynamic linking en dynamic loading. Waarschijnlijk is geen enkele vorm van 

automatische gathering mogelijk bij dynamic loading. Maar bij dynamic linking kies je voor een 

vorm waarbij op compile-time de references worden opgelost, al worden ze op runtime 

gerealiseerd. Je offert daarom mogelijk een COM eigenschap op. 

Voor dynamic linking moeten alle objects zijn verzameld in één of meer shared libraries. We kiezen 

voor één om zoek problemen te voorkomen bij het binden van references. Dit gaat –,als het nodig is 

–, vooraf aan elke uitvoering van de linker. 

Bij het maken van een installatiefile zou mogelijk de reference data uit de executables kunnen 

worden samengesteld om te gebruiken bij het samenstellen van de uiteindelijke dynamic shared 

library van de objects uit de gpf folders. Het variant type dat hierbij gebruikt wordt: “target 

televisie”. Voor TriMedia en Standby processor is misschien static binding nodig, gesteld dat daar 

geen dynamic libraries zijn geïmplementeerd. Variant type “target computer” moet daarin eventueel 

voorzien. 

Pagina: 161 / 230




Een manuele methode zou in de basic dians kunnen worden bijgehouden. De gebruikte idl 

interfaces van de modules in notice worden door de programmeur geboekt in de betreffende base 

dian. Zo wordt een selectie van idl files expliciet toegevoegd aan de build outline. Ook deze 

informatie is mogelijk afhankelijk van het variant type “target televisie”. Op die manier is per target 

bekend welke idl files betrokken zijn. De idl outlines die zo verzameld kunnen worden in een file 

zijn een bijproduct bij het maken van de executable. Ze worden bij het samenstellen van de 

uiteindelijke dynamic library gebruikt als secondary input. 

Fase één secondaire inputs 

Een script node moet eerst opgezet worden, en kan dan pas vuren. Input files en outlines bij het 

opzetten: 

● De varianten file. 

● df files. Om de folders van de output files te selecteren. We nemen aan dat een sio file maar 

in één folder terecht mag komen, voor de meeste andere output files geldt dat ook. Om df 

files te achterhalen is er misschien een outline van df files nodig, waaruit de juiste wordt 

geselecteerd. Merk op dat de folders waarin output files komen niet hardcoded voorkomen 

in het script van de node, maar uit de geselecteerde df file gehaald worden. 

● Het generatie tool zelf. 

● De outlines voor de secondary inputs 

Koala en bib 

Onze rigide build methode heeft een probleem met Koala. Koala genereert een header file die 

ingelijfd wordt in een c file. Dit moet net omgekeerd zijn. Voor onze build methode is dit fout. 

Koala moet een primary input file genereren waarin de andere file geïmporteerd wordt. Na de Koala 

push-position start de push-position van deze files. Precies die files die Koala in de betreffende 

derived folder achter laat worden gebruikt in Push. Daarom moeten juist zij de primary inputs zijn. 

De files zijn een subset die door het Koala engine zijn bepaald, aan de hand van compile time 

diversity. Als in plaats daarvan de c files zouden worden gecompileerd zou dat leiden tot veel fouten 

omdat de header file kan ontbreken. 

Waarschijnlijk is de huidige omkering een legacy optie van Koala en hebben NXP en CE jarenlang 

opgezien tegen de wijziging van een fout die misschien al in de vorige eeuw ontdekt werd. In een 

dual window televisie bijvoorbeeld komen veel components in tweevoud voor. Er is dan één 

component met twee instances. Voor iedere instance genereert Koala een header file voor een c file 

die behoort tot de component. De bijbehorende c file moet dus twee keer gecompileerd worden, één 

keer met de ene h file, en één keer met de andere. Het script voor de compilatie van een Koala 

module zou de name van de h file als een parameter moeten doorgeven aan de compiler, zodat die 

tenslotte ingevuld kan worden in het #include statement van de c file. Het script moet natuurlijk 

ook de name van het c programma selecteren uit de name van de header file. De omkering is, als ik 

mij goed herinner, slecht één van de fouten: in de c programma's wordt mogelijk verkeerd 

omgegaan met instance names. Tot aan mijn pensionering werd een omslachtige en onderhoudsgevoelige 

methode gebruikt om maar geen gebruik te maken van meerdere instances van een 

component. De c files konden hergebruikt worden, maar de cd files werden in tweevoud 

bijgehouden. 

Pagina: 162 / 230




Koala is een build system van zichzelf, die een aantal output files van de vorige keer opnieuw 

inleest om aan de hand van gewijzigde input de wijzigingen door te voeren. Momenteel gebruikt 

Koala zijn eigen sio file, maar eigenlijk kunnen Koala en build er één delen. Eigenlijk hoeft build 

geen dependency list op te slaan omdat Koala er één gebruikt. De Koala build is niet te doen met 

Push, vandaar. Zo'n build in een build kunnen we in veel eenvoudiger vorm ook zien bij sommige 

linkers en archivers. We zouden ze bib kunnen noemen: build in build. 

Ook de test harness generator is een bib. 

Bib Coöperaties 

Pull make is mogelijk te implementeren als bib. De nodes in make worden tweemaal bezocht, voor 

een activiteit. Eenmaal heen en eenmaal terug. De heenweg visite zou gebruik moeten kunnen 

maken van de outliner voor de primary sources, de terugweg visite benut outlines voor de secondary 

input files. 

Koala bepaalt bij een cd file de outline van id files en h files. De outliner zou die kunnen leveren. 

Een bib zou een alternatief voor sio files kunnen gebruiken. De sio file die push gebruikt zou dan 

slechts de fase één inputs bevatten. 

Globals 

Er is een centraal document waarin een aantal zaken vermeld zijn: 

● Variant types en een opsomming van hun varianten 

● File-types 

Build filetypes eisen soms een verfijning van de normale filetypes. Bijvoorbeeld: de h files 

die gegenereerd worden door Koala worden gerekend tot een filetype die een primary input 

is, terwijl de c file die een Koala module representeert slechts een secondary input is. Er 

moet een list zijn van Build filetypes. dians weten van hun files tot welk build filetype ze 

behoren. 

● Generatie tool 

Er moet een template zijn van zijn script node. 

● Push-position 

Bij een push-position horen een generatie tool, een primary input type, en een volgnummer. 

Het volgnummer bepaalt ook het sio subtype. Enige opties als: “altijd vuren”, “Tool als er 

niet gevuurd moet worden” en zo. Frivool is een lijstje generatie tools, ieder met een 

primary input type, en eventuele opties. 

● Binnen de NHSW tree kunnen restricties bestaan voor bepaalde typen secondary input files. 

• Een secondary file mag alleen gebruikt worden. als de primary file tot dezelfde 

component behoort. Restrictie: component. 

• Een secondary input file mag gebruikt worden als de primary input hoort tot het 

package. Restrictie: private 

Pagina: 163 / 230




• De secondary input file heeft geen restrictie: public. 

Scoop typen vormen een globale lijst. 

● We gingen ervan uit dat binnen de dian outliner een file referentie bestaat uit het paar (file 

name, dian). Voor id files en h files geldt bovendien dat ze vanwege de scoop waartoe ze 

behoren dat de component name en package name toegevoegd zijn aan het tuple. Dat is 

daarmee een goed idee voor alle files. Nu build filetypes kunnen afwijken van gewone 

filetypes, kunnen die ook het best aan het tuple worden toegevoegd. 

Dians voor buildgraph afbakening, overwegingen 

Dians zijn objecten die een aantal functies implementeren. De meeste functies retourneren een 

outline. Voor afbakening van een buildgraph kan de outliner vragen om een outline gegeven een 

bepaald filetype. Voor afbakening ten behoeve van secondary files kan de outliner vragen om een 

outline gegeven een bepaalde restrictie en een bepaald filetype. Ze retourneren outline indexen van 

de files die ze in notice hebben, en de outliner moet die samenstellen tot één geheel. In frivole 

oplossingen kunnen de basic dians ook een lijstje retourneren van andere dians. Ze kunnen het 

package retourneren waartoe ze behoren, en of ze private zijn of public. De meeste dians zijn basic, 

maar er zijn enkele speciale. Dians zijn bedoeld als een oase van standaardisatie in een NHSW tree 

vol legacy en verschillen tussen teams. 

In frivole oplossingen vormen basic dians een verzameling trees. Een tree bevind zich in een 

package, meerdere trees kunnen voorkomen in een package. Een tree ontstaat omdat een dian een 

aantal anderen in notice heeft. Nog frivoler wordt het als trees trees in notice hebben, en dan vooral 

trees buiten het eigen package. De toppen van de trees in een package kunnen public zijn of private. 

Een dian uit een ander package mag public trees in notice hebben. In rigide oplossingen zijn basic 

dians niet gekoppeld. De top in een package is een entry dian. Een entry dian heeft df files in 

notice, en basic dians. In de folders die afgeleid zijn van de df files komen derived files terecht ten 

gevolge van de eigen primary input sources. Deze derived files zijn op hun beurt weer primary 

input, of zeer precies afgebakende secondary input, als gathering ontbreekt. 

Er zijn df dians. Die hebber derived folder files in notice. In rigide oplossingen hebben ze basic 

dians in notice. Die op hun beurt hebben de primary inputs in notice voor de derived files die in die 

folders moeten worden opgeslagen. In frivole oplossingen hebben ze trees van basic dians in notice. 

Let wel de notice wordt niet gebruikt voor de afbakening van de buildgraph, maar voor onderhoud 

van een derived folder. 

Er zijn start dians. Misschien is elke df dian ook een start dian. De outliner bepaalt via de 

substructuur die door de start dian afgebakend wordt wat de primary input outline is. Mogelijk 

speelt de start dian ook een rol in het afbakenen van secondary input outlining (zie de sectie over 

global public, en local public). In een rigide systeem hebben ze basic dians door de hele NHSW tree 

in notice, in frivole systemen hebben ze de toppen van trees in notice. 

In een frivole oplossing is de notice van dians verspreid over de hele verzameling dian files. Bij 

rigide systemen zijn ze geconcentreerd in enkele start en df dian files. Waarom frivool? 

● In een rigide structuur betekent een wijziging in de constellatie van dians in een package dat 

meerdere start en df dians moeten wijzigingen. In een frivole structuur wordt alleen lokaal 

gewijzigd. 

● In een rigide structuur: bij elke wijziging van de structuur wijzigt de start node, die wordt 

Pagina: 164 / 230




dus veel gewijzigd, en moet vaak overgedragen worden aan Climbexion, dus merge met de 

bijdragen van velen is gegarandeerd. 

Als de structuur frivool verspreid is over de dian files worden ook de wijzigingen verspreid 

over de files en hoeft merge minder vaak te worden gebruikt. 

● In een rigide structuur kan een wijziging binnen een package ook een wijziging van starters 

betekenen in andere packages. 

In een frivole structuur kan gezorgd worden voor stabiele entry-points in een package, zodat 

wijzigingen binnen een package geïsoleerd kunnen plaatsvinden. Ook overgangen binnen 

een package naar een ander stelsel entry dians kunnen zo georganiseerd worden dat teams 

elkaar niet blokkeren. 

● In een rigide structuur wijzigt Cunie een constellation binnen een package en loopt daarna 

de df en start dians na, of die ook gewijzigd moeten worden. Lagus maakt ondertussen een 

nieuwe starter of een nieuwe df dian aan, die gebaseerd is op de oude constellation. Beiden 

dragen hun wijzigingen ongeveer tegelijk over aan de transfer drawer. De kans dat dit 

gebeurt lijkt met de rigide oplossing veel groter dan met de frivole. De rigide oplossing lokt 

“Lagus & Cunie” uit. 

Waarschijnlijk initialiseert de outliner door een sessie node te maken voor iedere dian. In de starter 

nodes en df nodes kan de buildgraph wordt vereenvoudigd tot outlines en opgeslagen. In de basic 

nodes kunnen alle pointers bidirectioneel worden uitgevoerd. Sessie nodes kunnen ook worden 

gebruikt om outlines, die reeds zijn bepaald, op te slaan voor later gebruik. Door goed te 

initialiseren is het voor een script node redelijk efficiënt om bij een primary input file een derived 

folder te vinden, en omgekeerd. 

De outline van alle primary inputs voor een target build moet zo precies mogelijk zijn, anders wordt 

er te veel gewijzigd. Outlines voor import in generatie tools mag vaak ruim zijn, de gatherer van het 

generatie tool lijft alleen in wat nodig is. Als een tool zo gebruikt wordt dat die altijd de hele outline 

van de input inlijft, dus zonder gatherer, dan moet de outline zo natuurlijk zo precies mogelijk zijn. 

Dat is de normale manier om met een linker om te gaan 

Ik weet niet of het voorkomt, een derived file bij de ene df dian is primary input voor een folder in 

een andere. Als het kan kunnen mogelijk cross verwijzingen voorkomen, en moet de outliner 

daarmee rekenen. 

Dians kunnen zich bevinden in een folder van het package of op afstand staan, of zelfs met 

meerderen in een file al dan niet op afstand. Deze implementatie details doen momenteel niet ter 

zake. Een feit is dat ze een aantal folders van een package in notice hebben met de files die er 

instaan. Ze bevatten een referentie naar die folders. 

Een package kan read-only zijn, in dat geval worden derived folders in het package beschouwd al 

source folder. 

Secondary input outlining 

buiten de primary input outlines van een starter dian. Misschien komt er een extra dian, de tree dian, 

die helpt bij het maken van public outlines van secondary input files. Ook komen er package dians, 

die de outline verzorgen van de public files, en de outline van de package restricted files. 

Pagina: 165 / 230




Basic dians in een package 

In plaats van het strikt volgen van de componenten structuur van Koala is een structurering binnen 

een enkele entry dian mogelijk, waardoor en maar één is per public component, één per test harness 

één per tool, indien daar source van zijn. De primary input dian heeft dan een lijst van de 

componenten in notice, waar Koala een tree heeft. Per component zijn dan speciale vermeldingen 

mogelijk, zoals c files die niet door Koala gebruikt worden en zo. De dians die hij in notice heeft 

zijn dan dians in een ander package, of df dians in eigen package. Er is natuurlijk wel enig risico om 

hier één per package van te maken, gegeven de discussie over rigide en frivole dian structurering. 

Een secondary source dian zou er kunnen zijn per package. Secondary input dians voor id, h, dd, 

files kunnen ver buiten folders van een primary input outline. Deze dian maakt deel uit van een 

structuur die overeenkomt met de structuur van de working-tree in dit geval een subset: een package 

tree. 

In een mixed tree omgeving zou een algemene outliner de specifieke van Koala kunnen vervangen. 

Voor Koala Componenten zou de outliner de Koala files kunnen gebruiken in plaats van de dians, of 

dians creëren uit Koala files. In packages zonder Koala zullen ze dan met de hand gemaakt moeten 

worden. Als een team ze niet mee levert bij een package, dan kunnen ze gemaakt worden in een 

folder die op afstand staat van het package. Een dian kan het entity type van een folder lezen. Dit 

type is reeds aanwezig in de kin. Hiermee “weet” een dian of de folder een interface folder is, of 

een koala component, of een com component, of wat voor entity type dan ook. 

Target directed df dian 

Sommige df folders zijn er voor executables. De primary inputs van de executable en van Koala 

moet zich bevinden in de primary input outline van de target df dian. Ook de df file voor de koala 

folder waarin die de header file plaatst, en mogelijk nog één voor de database die nodig is om 

wijzigingen door te voeren als Koala de volgende keer start, staan hier in notice. Om de executable 

up-to-date te maken moeten zij zich, samen met de df dian bevinden in de outline van de start dian. 

Opnieuw df files 

Derived folder files definiëren folders voor derived files. Deze folders bevindt zich samen met de df 

file in een gewone folder, tenminste als ze reeds bestaan. 

Van elke folder is gespecificeerd welke filetypes hij kan bevatten. Dit staat in de df file. Folders 

voor de opslag van sio files bevatten uitsluitend sio files. 

Secondary input outlining voor id, h, dd, pd, idl files kunnen de hele NHSW tree benutten. Ook de 

gespecificeerde folders ontvangen de outputs van de betreffende script nodes. 

Variant folders moeten mogelijk onderhouden worden. Welke varianten bij een folder moeten 

worden onderhouden hangt waarschijnlijk af van een generatie tool uit de push-position. Het 

generatie tool zelf kan een variant zijn, of minstens één van zijn input files kan een variant zijn. 

Afhankelijk van de varianten frivoliteit van de output files, moeten er een varianten folders worden 

gemaakt. 

De folders van een gewijzigde df file die betrokken is bij een build worden gecontroleerd op op hun 

eigenschappen. Deugen filetype en push-position in de folders nog wel? Na een wijziging vervalt 

Pagina: 166 / 230




alles in de folders dat niet voldoet aan de specificaties, eventueel vervallen oude folders, nadat hun 

bruikbare inhoud is gekopieerd in de nieuwe. 

Eisen aan tools 

● Van een tool wordt verwacht dat die zijn dependency list kan produceren, dat zijn gatherer 

dit lijstje maakt. Bij voorkeur met version informatie. 

● Als een tool een variabele aantal output files produceert, Dan wordt verwacht dat die zijn sio 

file kan produceren. Bij voorkeur doet elk tool dit. Bij voorkeur met version informatie. De 

inputs in fase 1 van de script nodes hebben reeds een dependency list opgeleverd. Die kan 

worden toegevoegd aan de sio file van het tool. 

● Een tool moet voor zijn secondaire input gebruik maken van de outlines die door de outliner 

gemaakt worden. De rigide outliner levert outlines in de vorm van een index van files, Als 

een tool uit de outline kan breken, of geen raad weet met een geleverde outline dan zou de 

script node moeten voorzien in conversie. Mogelijk met behulp van de outliner, die 

misschien een lijstje folders kan leveren, in plaats van files. 

● Een tool dat een ernstige fout produceert moet een reset plegen. De output files die 

overschreven zijn, of die zijn vervallen moeten in oude staat hersteld worden. De fout moet 

adequaat worden doorgegeven aan script en push in uitvoering. Als reset niet goed is dan 

moet ieder geval het adequaat doorgeven op orde zijn, zodat output files en sio file kunnen 

vervallen. 

Tot slot. 

Al met al lijkt er met push en dians een build mogelijk waarmee midl, Koala, Harness generator en 

home-made generatie tools uitgevoerd kunnen worden, en waarmee gemengde oplossingen 

mogelijk zijn, dus Koala packages en non Koala packages zijn te combineren, omdat hun derived 

files, bijvoorbeeld de object files, gescheiden kunnen worden opgeslagen. Start dians voor één 

enkele executable zijn er voor programmeurs. Start dians voor meerdere executables zijn er voor 

build managers en programmeurs, en lijken te kunnen wedijveren met clean builds. Wel eist iedere 

variant combinatie zijn eigen build. Het zelf reinigende vermogen van het geschetste push algoritme 

en het gebruik van df files zou volledige clean builds moeten voorkomen. 

Pagina: 167 / 230



2.7 Security 

2.7 Security 

Het revision control system sluit aan bij de security van de server waarop iemand is ingelogd. De 

user-id die daarbij gebruikt wordt is de sleutel die toegang geeft tot het revision control system en 

die bepaald wat iemand mag zien en wat iemand mag bewerkstelligen. Een user kan behoren tot één 

of meer teams, werkzaam zijn in één of meer projects, en verscheidene rollen vervullen. 

2.7.1 Security entiteiten 

Rollen: 

● Administrator: Zij of hij registreert clients, teams, projects, users, packages, locations, pools, 

drawers en hun samenhang 

● Build manager: Deze beheert de inhoud van drawers en constellations, plaatst elements in 

centers vanuit transfer drawers, importeert, en exporteert. 

● Developer: Zij/hij bezit (create/delete/empty) één of meer satellites van de team-drawer, en 

een location voor pools en drawers. 

● Tester: bezit één of meer satellites van de test drawer, en mogelijk ook van de team-drawer, 

en een location voor pools en drawers 

● Architect developer, architect tester: kan ook de attributes van kins onderhouden. 

● Integrator: bezit één of meer satellites van de team-drawer, en mogelijk ook van de mergeimport 

drawers en baseline-drawers, en een location voor pools en drawers 

● Guest: Een guest krijgt toegang tot sommige drawers, working-trees en info-trees. Ze mogen 

erin kijken. Niet alle guests krijgen dezelfde toegangsrechten. Afhankelijk van de export 

limitations die voor hen gelden krijgen ze toegang tot een bepaalde export-drawer, of ze 

mogen alleen bij een expose-drawer. Kijken en downloaden (exporteren) zijn hun 

mogelijkheden. 

● Project leader: Deze heeft mogelijk slechts indirect, via medewerkers toegang tot de 

repository, tenzij de project documentatie en de status reports worden opgeslagen in de 

repository, dan moet hij in ieder geval toegang hebben tot deze documenten. 

● Change manager: Deze gebruikt de repository voor project evaluaties, statistieken en zo. 

● Configuration manager: Deze benoemt en beheert de locations, pools, drawers en 

constellations, installeert Climbexion, en mogelijk het work-item system, en build system, 

import/export limitations en scripts en dergelijke. 

Organisaties: 

● Party: Een organisatie. We onderscheiden NXP, client, third party. De owner van een master 

project heeft de rol van client. 

● Team. Voor een team kunnen er export limitations gelden voor packages die in beheer zijn 

bij andere teams. Vaak is dit het geval als de teams behoren tot verschillende parties. 

● Project: Een tijdelijke organisatie waarin verschillende teams van verschillende parties 

participeren. Vaak is er een project leader per party (soms meerdere, als er veel soorten 

televisies ontwikkeld worden, of als een party meerdere producten (bijvoorbeeld chips) 

onderhoudt). We onderscheiden een master-project: het overall (software) project van de 

klant, en subprojects: waarin een deel van de software wordt opgeleverd. Het team in een 

Pagina: 168 / 230



2.7 Security 

Objecten: 

subproject behoort tot één party, en is verantwoordelijk voor een deel van de software. 

● Drawer: Hiervoor gelden toegangsrechten van teamleden, afhankelijk van de rollen die ze 

vervullen. Voor leden van andere teams gelden guest rechten, die afhangen van de party 

waartoe het team behoort. De toegangsrechten bepalen ook de rechten op de files die tot de 

inner-reach van packages behoren, en de versions die tot de courses van de files behoren. 

Ook het satellite recht behoort tot de toegangsrechten., De sheets van patches die zijn 

aangebracht op de drawer zijn toegankelijk als de drawer toegankelijk is. De bij een patch 

behorende envelope is toegankelijk met de patch, en ook de envelopes die genoemd worden 

in de events van de courses van elements in de drawer zijn toegankelijk. 

● Package: de toegangsrechten zijn afhankelijk van het ownership, en van de drawer waarin 

het package zich bevindt. 

● Pool: voor versions, kins, envelopes zijn er de pools, met toegangsrechten tot een pool 

kunnen beperkingen plaatsvinden van de files waartoe men inzage heeft. 

● Location: Waarin de pools staan voor de versions binnen packages, voor de kins binnen een 

package, voor de envelopes binnen een subproject, voor drawers. Een location representeert 

een organisatorische eenheid, zoals een persoon met satellites op een PC, of een team of een 

groep teams binnen een party, met center-drawers op een server, of in een cloud. 

● Files, Folders, Soft-links: Deze objecten kunnen geheimen bevatten, of ernaar verwijzen. 

2.7.2 Security doelen en middelen 

Te bereiken discretie. Party en team discretie. 

● Geheime algoritmes. Als de algoritmes in de software van een team een concurrentie 

voordeel opleveren, dan zal men ze soms geheim willen houden. Zo zal NXP bepaalde 

algoritmes niet in source vorm beschikbaar stellen aan klanten, of andere partijen in een 

master project. Soms implementeert NXP geheime algoritmes van klanten in zijn software, 

en mogen die algoritmen niet gebruikt worden in projects van andere klanten. 

● Actualiteit. Een team dat meerdere projects bedient, mag soms geen actuele gegevens, 

(requirements en change requests, problem reports, project states, test results, plans) lekken 

van het ene project naar het ander, bijvoorbeeld als er concurrentie of competitie bestaat 

tussen de projects. Een probleem dat gevonden is bij de één en ook opgelost moet worden 

bij de ander, mag dan geen verwijzingen naar de één bevatten. Dit beperkt de gegevens in 

bijvoorbeeld envelopes, referentie naar en citeren uit problem reports als comment in source 

code e.d. Voor Climbexion betekent dit dat niet méér informatie op een scherm verschijnt 

dan nodig is. 

In mijn voorbeelden van envelopes vermelde ik “Client, Team en Project”, maar project is 

voldoende. Voor degenen voor wie het bedoelt is zijn dan team en client en master project 

bekend. Ook bevat een envelope herkomst informatie als referenties naar parallelle projects, 

en original en neighbor gegevens. Deze gegevens mogen niet getoond worden buiten de 

teams die het package beheren. In baseline reports moet daarom verwezen worden naar een 

work-item extractie die dergelijke gegevens niet bevat. 

● Way of working. Waarschijnlijk heeft dit geen directe invloed op Climbexion. De way of 

Pagina: 169 / 230



2.7 Security 

working die door één party vereist wordt kan uiteraard invloed hebben op de way of 

working van een team in het algemeen. Maar het is niet netjes om hier de competitie tussen 

parties te beïnvloeden door te lekken. 

Soms bestaat er competitie tussen projects zelfs van één client. In het verleden is het zelfs zo 

geweest dat Philips verschillende merknamen gebruikte, en dat die merken vooral elkaar op de 

markt beconcurreerden. Het niet aan Climbexion of NXP om de gegevens van het éne project te 

lekken naar het andere. Tussen de projects van een client kunnen soms hoogstens afspraken worden 

gemaakt over de verdeling van capaciteit. 

Anderzijds kan het zo zijn dat een client een aantal projects heeft lopen, bijvoorbeeld per 

marktsegment, of per regio, en dat uitwisseling van informatie (kruisbestuiving) gewenst wordt. Er 

zijn dus projects waartussen informatie uitwisseling integraal moet plaatsvinden, maar ook projects 

waarin teams niet prijsgeven of bepaalde oplossingen of probleem beschrijvingen uit het ene project 

zijn overgenomen in het ander project. We zullen het begrip "party"gebruiken: als master projects 

tot dezelfde party behoren wisselen allen gegevens integraal uit, maar als master projects tot 

verschillende parties behoren, dan wordt het uitwisselen van informatie beperkt en blijft binnen de 

afzonderlijke teams. Gegevens over een wijziging in een package beperken zich dan tot de teams 

die het package beheren. 

Stel je eens voor dat de laatste hobbel die genomen moet worden om van Climbexion het 

wereldwijde standaard systeem te maken voor het opslaan van TV software, dat dat het 

beveiligingssysteem is. Dan moet de verlangde discretie overtuigend bereikt worden. Ik vond een 

artikel van Dorothy E. Denning: “A Lattice Model of Secure Information Flow”. Communications 

of the ACM May 1976, Volume 19 number 5. Er komt een fase in het ontwerp waarin het datamodel, 

de processen en de menselijke rollen volledig in kaart zijn gebracht. Dan moet dit Lattice model 

gemaakt worden en tonen dat de discretie en geheimhouding gewaarborgd is. Hopelijk is een 

statisch model voldoende voor de data entiteiten. Dan moeten er nog waarborgen komen dat de 

repository uitsluitend integere climbexion software gebruikt, dat de mensen die Climbexion 

gebruiken zijn wie ze zeggen dat ze zijn, dat het niet mogelijk mag zijn om van buiten af 

waarnemingen te doen omtrent data in het revision control system of in de communicatie tussen de 

processen. Dat er dergelijke eisen aan zo'n systeem worden gesteld in een situatie waarin “trade 

secrets” worden gebruikt is normaal: degene die recht heeft op een geheim, moet soms kunnen 

aantonen dat het geheimhouden beveiligd was, en dat er “inbraak” nodig was om te komen tot een 

schending van het geheim. Waarschijnlijk behelst het totale lattice niet slechts de classificatie van 

files, maar ook die van drawers, pools, packages en dergelijke. 

Een repository is niet een alles omvattend systeem, en dat geldt ook voor de beveiliging van het 

systeem. De tralie van Dorothy Denning betreft de repository elements waaraan security classes 

worden toegekend. Waarschijnlijk worden mensen dynamisch gebonden. Ze zijn dan tijdelijk een 

entity waarheen, in een transaction informatie stroomt, die mogelijk na bewerking weer 

teruggevoerd wordt naar de repository. De classificatie van de terug te geven elements is dan de 

mogelijk de kleinste bovengrens van betrokken geraadpleegde elements. Mogelijk is voor zo'n mens 

een boven-grens gedefinieerd van de classificaties die voor haar/hem toegankelijk zijn. Verder reken 

je op haar of zijn discretie. 

Een build procedure is een process entity waarheen versions van geclassificeerde elements kunnen 

stromen, en die dan een resultaat leveren dat lager is geclassificeerd dan het supremum van de 

inputs. Immers de geproduceerde binary wordt geacht de geheimen te verbergen, die in de source 

Pagina: 170 / 230



2.7 Security 

files aanwezig zijn. Dit is faliekant in tegenspraak met de worst case aanname dat het opgeleverde 

resultaat de betreffende geheimen onthult, aan ieder die er toegang toe heeft, en dus het supremum 

als classificatie moet hebben. Er zal dan ook af en toe ingegrepen moeten worden op zo'n rigoureus 

geautomatiseerde beveiliging. 

Als je wilt komen tot een verfijnd systeem van export limitations middels een classification 

methode, dan is er een periode, na het opstarten van het project, dat de classifications niet op orde 

zijn. Gedurende die periode mogen alleen ingewijden toegang hebben tot de repository. 

Naast al deze eisen aan Climbexion, is er nog een middel dat gebruikt wordt. Een TV fabrikant kan 

NXP vereenvoudigde of oudere packages ter beschikking stellen. De werkelijke status van zijn 

software is dan niet bekend binnen NXP. Dit kan ten koste gaan van het vermogen om fouten te 

reproduceren en op te lossen. Voor Climbexion zou dit betekenen dat niet iedere baseline van iedere 

package in een master project beschikbaar is voor iedere party. 

Een vergelijking van export limitations ten opzichte van verouderde packages: 

Onderwerp Export limitations Oud package 

Onderhoudbaarheid Simpel ?? 

Review op package Ingewijden Ingewijden 

Testen van product Allen Ingewijden 

Fout reproduceren Allen Ingewijden 

Fout analyse na product-test Soms allen, soms ingewijden Ingewijden 

Het gebruik van een dergelijk substituut is in wezen niet aan te bevelen omdat de independent 

deployment van Szyperski niet bereikt is. Het was in ieder geval nog niet bereikt toen ik 

gepensioneerd werd. Anno 2008 moest de software van NXP nog steeds getest worden met de tv en 

software van een klant. NXP zou dat zelf moeten kunnen doen. In ieder geval zouden ze een fout 

zelf moeten kunnen reproduceren en analyseren. 

Het one-roof gebeuren stelt specifieke eisen aan de discretie: ieder team kan beschikken over kennis 

die men niet wil delen met leden van een ander team, maar de leden zitten soms wel quatre main 

achter één display met toetsenbord. Ik weet niet hoe je onder die omstandigheden discretie 

waarborgt met functionaliteit van software. Voor Climbexion ga ik dit niet oplossen. 

Herkomst garantie 

Als teamlid Lepus een wijziging aanbied, dan wil je zeker weten dat het inderdaad teamlid Lepus is 

die de wijziging stuurt. De changesets en versions in een envelope zullen worden voorzien van een 

content hash. Versleuteling van de hash met haar private key, en controle met haar public key 

moeten waarborgen dat de wijziging inderdaad van Lepus afkomstig is. Elke transfer van een 

envelope kan uitgevoerd worden door een andere persoon, en zal een andere versleuteling van de 

hashes betekenen. De envelope waarmee een te exporteren baseline is gerealiseerd moet zichtbaar 

en verifieerbaar zijn voor degene die importeert. Voor external envelopes geldt hetzelfde. 

Waarschijnlijk worden public keys geregistreerd door administrators die ze via vertrouwde kanalen 

verkrijgen, die daardoor de rol van waarborg krijgen. De administrator database speelt hier een 

belangrijke rol. 

Pagina: 171 / 230



2.7 Security 

Database garantie 

Als je inlogt op een center-drawer, dan moet het gewaarborgd zijn dat je inderdaad inlogt op de 

betreffende drawer. Inloggen doe je via de administrator database, die je in verbinding brengt met 

het betreffende drawer. Ook van envelopes moet gewaarborgd worden dat ze zijn die ze zijn. En 

verder moet de administrator database zelf een toppunt van vertrouwen zijn. Niets mag fake zijn, 

alle inhoud van een database moet via een regulier en vertrouwd process zijn aangebracht. Ook de 

integriteit van de courses, de versions, de drawers en packages kan waarschijnlijk met 

(cryptografische) checksums en elektronische handtekeningen worden gewaarborgd. Ik denk dat 

hiervoor aardig wat beveiligings-techniek komt kijken. In het begin van Climbexion is mogelijk nog 

niet alles beveiligd. 

2.7.3 Gentlemen agreements 

Er zijn een aantal afgesproken regels die niet echt of volledig afdwingbaar zijn met 

beveiligingssoftware. Overtreding van dergelijke overeenkomsten kunnen partijen of projects in 

problemen brengen. Discretie is er één. Niet wijzigen in de software van een ander is er ook één. 

Climbexion is waarschijnlijk niet in staat, om overtreding van zo'n overeenkomst onmogelijk te 

maken. Climbexion moet natuurlijk wel zo gemaakt worden, dat het mogelijk is om je aan de 

agreements te houden, of zelfs dat overtreding niet wordt uitgelokt. 

De baseline supplements discipline: 

De owner van een package is de enige die de patch uitgeeft. 

Dit moet onder andere voorkomen dat lokale wijzigingen in andermans packages tot gevolg hebben 

dat nieuwe baselines van een package niet meer kunnen worden ingevoerd, of dat een team niet 

langer aansprakelijk kan zijn voor de werking van zijn package in een project. Nu er local pools 

bestaan is er niets afdwingbaar. De discipline zou als volgt ondersteund kunnen worden met 

security middelen: kins en versions kun je slechts gebruiken en importeren maar niet maken in een 

package waarop je geabonneerd bent maar dat je niet beheert. Maar op het moment waarop iemand 

een patch voorbereid voor een package van een ander team, dan zou de security toch omzeild 

moeten worden, of zou er buiten Climbexion om moeten worden uitgewisseld. Dat laatste is 

natuurlijk niet de bedoeling: Climbexion is er immers voor de uitwisseling. 

Export limitations: 

Deze worden gebruikt als een krakkemikkige methode om algoritmen geheim te houden. De 

gedachte is dat broncode noodzakelijk is om het geheim te leren kennen. Er is natuurlijk wel iets 

prijsgegeven: er is bijvoorbeeld een brochure waarin de loftrompet wordt gestoken over het 

algoritme, en er is gedocumenteerd hoe het algoritme geïntegreerd en geïmplementeerd moet 

worden. Met “reversed engineering” technieken zijn de algoritmen mogelijk toch te achterhalen. Er 

zijn zeer expliciete methoden: 

● Zo kun je de beschikbare software inbedden in een test-harnas en testen, om te achterhalen 

hoe ze werken. 

● Het doel van “machine code” is om een taal te maken die gemakkelijk is voor computers, 

maar niet om een taal te maken die onmogelijk is te lezen voor mensen: er zijn dan ook 

disassemblers die helpen bij het leesbaar maken van machine code. 

Deze methoden zijn inderdaad omslachtiger dan het gebruik van broncode. Verder moet je als je 

soortgelijke broncode wilt vervaardigen een ontwikkelingsproces volgen, dit is zeker omslachtiger 

dan het kopiëren van kant en klare broncode: bescherming tegen domweg kopiëren lijkt 

Pagina: 172 / 230



2.7 Security 

gewaarborgd , maar het beschermen van uitvindingen en ideeën niet. 

Het lijkt erop of software octrooien uit de gratie raken en dat vooral auteursrechten gaan gelden 

voor software. Dit is een ontwikkeling die rond de eeuwwisseling nieuw was voor chip en set 

makers: hardware octrooien zijn normaal, en met software octrooien lijken er altijd problemen te 

zijn. Vermoedelijk is het geheimhouden van algoritmes van korte duur, je profiteert in nieuwe 

televisies een half of een heel jaar van een nieuw algoritme, of een noviteit, en daarna wordt de 

implementatie geëvenaard of overtroffen door jezelf en de concurrentie. Misschien wordt dit de 

trend: je houdt software algoritmen een tijdje geheim en nadat je iedereen ermee verrast hebt maak 

je er GPL software van. 

Problemen met rechten op embedded software werden tot in de jaren negentig vaak vermeden. De 

software was er voornamelijk voor de gebruikers interface. Software werd (en wordt) “gratis” 

weggegeven bij de verkochte chips. In de praktijk was men er vaak guller (officieel: slordiger) mee, 

dan volgens het officiële beleid. De simpele gebruikers interface is inmiddels uitgegroeid tot 

“applicaties” en ook vervangt software hardware. De kosten van ervan zijn gigantisch geworden en 

de hoeveelheid chips of televisies met dezelfde software uitgave zijn kleiner geworden. Kortom 

software is geen weggevertje meer. De prijs ervan is nu significant aanwezig in de prijs van een 

televisie of in de prijs van een chip. 

Voor mensen is expertise en communicatie belangrijker dan broncode om zich een idee te vormen 

omtrent de algoritmen. Pas voor de laatste details is soms broncode nodig (of reversed 

engineering). Bijvoorbeeld, goed en kwaad leer je niet uit het wetboek van strafrecht (de broncode), 

maar je verwerft expertise door middel van communicatie en na-apen (de opvoeding). Misschien 

moet je je soms wel verdiepen in de details van een stukje wet. Voor zo'n wetboek gelden allerlei 

regels en gebruiken die we zullen samenvatten met de opmerking dat het “een wetboek” moet zijn. 

Door je kennis soortgelijk in “wetboek” fragment te gieten, lijkt het al een beetje op het echte 

wetboek fragment. Gaten en leemten zijn mogelijk meteen duidelijk. Door je eigen (denkbeeldige) 

stukje wetboek onbetrouwbaar te achten kun je een plan maken van de details die je wilt verifiëren 

(dit zijn gerichte of “gesloten” vragen). Als je niet beschikt over een wetboek, maar wel over een 

database met gerechtelijke uitspraken, dan kun je toch veel details achterhalen, die je denkbeeldige 

stukje wetboek verbeteren, tot niemand meer een verschil merkt met het echte. Je zou de methode 

kunnen noemen: van raden naar weten. 

Ik heb zo'n methode dikwijls gebruikt om me snel in te werken in een project. En vaak bij het 

analyseren van fouten of het vermijden van regressie: eerst bepaal je hoe je denkt dat het gedaan is, 

of desnoods hoe je iets zelf zou doen of maken: je gebruikt reeds verworven expertise. Dan test, kijk 

en vraag je hoe het gedaan is. Eerst vul je leemten in je kennis, dan verifieer je je kennis. Alles wat 

voorhanden is en iedereen die beschikbaar is is potentieel bruikbaar. In alle beschikbare 

informatiebronnen ga je gericht en systematisch zoeken naar de informatie die je nodig hebt. De 

methode is niet zonder gevaren: immers je begint met een vooroordeel, en misschien heb je niet het 

inzicht om te weten wat je niet weet. Voor “eye openers” is het daarom aan te raden om ook meer 

open vragen te stellen, en zeker ook om te communiceren met anderen. Voorbeeld van een open 

vraag: “hoe zou jij het doen?”. 

Pagina: 173 / 230



2.7 Security 

Kern van de methode is waarschijnlijk de verbeelding, waarmee je de voorstelling creëert waaraan 

je gaat werken, tot die de werkelijkheid benaderd. 

Export limitations worden gebruikt in organisaties met engineers van mijn slag, en de meesten zijn 

vaardiger, nieuwsgieriger, slimmer en beter opgeleid dan ik, in teams die veel expertise delen, 

immers in elke party is veel TV kennis. 

In een project waarin de software gemaakt, geanalyseerd en verbeterd wordt, en waarin dergelijke 

activiteiten moeten worden verdeeld onder de deelnemers is het vaak onvermijdelijk dat mensen 

zich een beeld vormen, – soms zelfs een gedetailleerd beeld –, van niet openbare algoritmen, 

immers ook die kunnen de schuld krijgen van een fout, of behulpzaam zijn bij het vinden van een 

fout. 

Minimale protectie, maar ietsje meer dan niets. 

In de stad waar ik woon, was vroeger een grasveldje met een bordje: “verboden op het gras te 

lopen”. Het grasveld was omgeven door een twintig centimeter hoog hek, zodat je wist wanneer je 

de overtreding maakte. Op snelwegen zie je dat veel asfalt is neergelegd, dat vervolgens 

afgeschermd is voor gebruik, door middel van een witte streep (??). Toen een overtreder bekeurd 

werd, werd zijn excuus “ik wist niet dat je kwaad werd” van tafel geveegd, maar toen iemand een 

bal van het gras haalde die een peuter er per ongeluk op geschopt had, rechtvaardigde de ernst van 

de calamiteit de overtreding. 

Export limitations zijn zo te implementeren dat ze maar iets hinderlijker zijn dan het bordje, het 

hekje, en de streep. Bijvoorbeeld door extra een ongelimiteerde export-drawer beschikbaar te 

stellen voor analyse en debugging, terwijl normaal met een gelimiteerde drawer wordt gewerkt. Als 

je kennis verwerft wordt je geacht te weten dat het een geheim betreft, en dat geheimhouding 

vereist is. Niet lekken is een gentleman's agreement. Gerealiseerde export limitations van zichzelf 

zijn niet erg duidelijk in het markeren van geheimen, immers de geheimen worden juist niet 

gepubliceerd. In de ongelimiteerde export-drawer zouden de geheimen goed gemarkeerd moeten 

worden, wat natuurlijk ook een risico inhoud. 

Nu ik erover nadenk, geloof ik niet dat dergelijke minimale protectie werkt in de samenwerking 

tussen elektronica multinationals. Die willen toch iets roofdierachtigs uitstralen iets van “lean and 

mean”. Zo'n regeling vinden ze geschikt voor watjes. 

Beschikbaarheid nadat het project beëindigd is: 

Voor evaluaties, voor het vermijden van regressie, misschien wel in juridische conflicten, en 

mogelijk zelfs voor de wetenschap is het van belang dat langdurig beschikt kan worden door alle 

betrokken parties, – en misschien soms zelfs door buitenstaanders –, over het ontwikkel traject van 

software in beëindigde projects. Hiertoe moeten afspraken gemaakt worden door parties over het 

gebruik van “original storage” waarin de packages, projects en subprojects worden bewaard. Het 

moet minstens “niet eenvoudig” zijn om original storage te vervalsen, zodat er een certificaat is 

voor de juistheid der historie, en het moet (politiek?, juridisch?, organisatorisch?) onmogelijk zijn 

om eigenmachtig original storage af te sluiten, of te vernietigen, of beschikbaar te stellen aan 

derden buiten de gemaakte afspraken om. 

Pagina: 174 / 230



2.7 Security 

Maintenance afspraken: 

Tot de afspraken in de vorige categorie behoren de maintenance afspraken. Onderhoud is meestal 

nodig bij “field calls”. Bijvoorbeeld als er compatibiliteitsproblemen zijn met een specifieke zender 

of een specifieke dvd speler of zo. Meestal duurt het onderhoudscontract, tot er een opvolger is van 

de TV, binnen de garantie periode wordt een field call dan opgelost door de slachtoffers de opvolger 

aan te bieden. Onderhoudscontracten hebben enkele smaken, bijvoorbeeld: 

● De party die eigenaar is van het package verzorgt het onderhoud nadat het project is 

beëindigd. De party levert expertise voor het herleiden van een probleem tot een oorzaak, 

wijzigt indien nodig eigen packages, voert er tests over uit, en brengt patches uit. 

● De party die eigenaar is machtigt een andere party, – mogelijk die van het master project –, 

om het onderhoud van de packages te verzorgen. Misschien levert de eigenaar (incidenteel) 

expertise. Deze optie zou strijdig kunnen zijn met het idee van discretie. Immers degene die 

een package onderhoudt heeft de beschikking over alle package variëteiten in alle 

subprojects waarin het package is gebruikt, ook die van concurrenten. Voorlopig komen 

hiervoor geen faciliteiten binnen Climbexion. 

Inner team security: 

Binnen een team heeft ieder lees-toegang tot center-drawers, envelopes, en dergelijke. Satellites zijn 

in principe slechts toegankelijk voor degene die ermee werkt, voor eigen evaluaties. Openbaar is 

echter de inhoud van de envelopes, maar die bevatten niet de history van de preparation state maar 

slechts het huidige resultaat. Dit komt overeen met de opvatting dat je iemand moet beoordelen op 

de resultaten, maar dat er enige privacy bestaat bij het realiseren van het het resultaat. Verder heb ik 

het liefst dat er gewerkt wordt met interactieve (Gui) climbexion add-ons, die de IDE uitbreiden, 

zodat wijzigingen definitief worden opgeslagen in de satellite als je op “save” drukt, en waarin 

mogelijk een “undo / redo” faciliteit komt, zolang je niet op “save” hebt gedrukt. Na save is de 

wijziging definitief. Je moet save natuurlijk niet eindeloos uitstellen: het is immers de bedoeling dat 

de course of development wordt vastgelegd, ook voor satellites. 

Pagina: 175 / 230



2.8 Overige aspecten 


2.8.1 Status en Progressie 

Het standaard status diagram van een element in Climbexion bevat de statussen: satellite, team, 

baselined. Bij een status hoort een kwaliteitsgarantie in de vorm van een regressie test en een scope, 

of wel een verspreidingsgebied, dat wil zeggen, de verzameling mensen die er normaal over 

beschikken. Daarnaast kan een status nog iets zeggen over het gebruik dat je van een element kunt 

maken. De standaard van Climbexion: Satellite, Team, Baselined, is de status die vanaf het begin 

wordt geïmplementeerd. 

Document status 

De architectuur van de software (we zullen architectuur hier opvatten als een aantal regels waaraan 

software en software ontwerpers moeten voldoen) eist bij public components en bij public 

interfaces een document, met een vastgelegde structuur. Dit is met name om semantische en 

pragmatische aspecten vast te leggen. Deze documenten, – en eigenlijk ook de interfaces en 

components die ze beschrijven –, doorlopen stadia. Ik meen dat dit het drietal: draft, exposed, 

accepted is. Voor interfaces is er nog de status obsolete, die is er om gebruikers aan te sporen om 

over te stappen op de opvolger; eigenlijk hoort hij in het rijtje niet thuis, omdat hij niet te maken 

heeft met kwaliteit, scope, en gebruik. Er is een tijd geweest dat er voor interfaces een folderstructuur 

bestond met de status namen, de folder “interfaces” omvatte in zijn memberset de folders 

“draft, en obsolete”, en verder de “accepted” files. Voor interfaces geldt een sterke binding tussen 

de status van het document en de status van de software: document en software worden gezamenlijk 

“in sync” bijgehouden. Voor components ligt het wat anders, als het document de status accepted 

bereikt dan kan het zijn dat de software nog gemaakt moet worden, maar soms is de software dan al 

klaar. Het gebruik en scope aspect is wel interessant, je kunt aan een document werken, je kunt het 

lezen, en je kunt het gebruiken (je implementeert de interface of component). De scope bestaat uit: 

de schrijver, een groepje reviewers en iedereen. 

Draft Exposed Accepted 

Schrijver Iedereen Schrijver Reviewers Schrijver Iedereen 

Werken aan: X X X*) X**) 

Lezen X X X X X X 

Gebruiken X X X X 

*) Indirect: de schrijver brengt de wijzigingen daadwerkelijk aan. 

**)Interfaces mogen niet gewijzigd worden, ze mogen slechts opgevolgd worden. 

Merk op: de draft status, die voor iedereen de komst van een component of interface aankondigt. 

Vaak wordt dit opgevat als: “gebruik voor eigen risico”. Oorspronkelijke betekenis: “ten behoeve 

van inspraak en planning: alleen voor informatie”. 

Interessant is de scope van exposed: Er is niet een vast team van reviewers, maar het groepje wordt 

adhoc samengesteld. Eigenlijk komt exposed nog het meest overeen met de envelope status 

“transferred”, waarbij gekeken wordt of de versions een build en een test doorstaan. Bij exposed 

Pagina: 176 / 230




wordt soortgelijk gekeken of een document een inspectie doorstaat. 

In de teams waarin ik werkte werd het review gebeuren als belastend ervaren. Architecten konden 

erin verzuipen, en ook anderen die zich naast hun eigen problemen en hun eigen competentie gebied 

ook nog eens intensief moesten inwerken in het werk van collega's konden de druk ervaren. De 

kwaliteits-officieren vonden dit onzin: een review hoefde toch maar een uur te duren: een half uur 

lezen, en een half uur praten. En daar hebben we ons toen maar aan gehouden. Toch kwam het soms 

voor dat reviews en inspections werden uitgesteld en uitgesteld, en iedereen met draft documents 

werkte. De kwaliteits-officieren hadden wel gelijk: in de status draft kan het document aan de orde 

worden gesteld in de meetings die architecten wekelijks houden, en kunnen mogelijk inhoudelijke 

wijzigingen worden aanbevolen; het review kan zich richten op zaken als duidelijkheid, 

volledigheid voldoen aan regels en dergelijke. 

Officieel werd gesteld dat na een wijziging (of een opvolging bij interfaces) de status weer draft 

moest zijn. In de praktijk werd het doorlopen van de toestanden slechts gedaan als een component 

of interface nieuw werd gemaakt, of bij aanzienlijke “delta processing” als het veel werk was om 

een component of interface over te nemen uit een voorgaand project. Daarna werd verondersteld dat 

er dermate zorgvuldig werd gehandeld dat de status “accepted” gehandhaafd bleef. In één enkel 

project was er dus sprake van progressie en zelden van cycli. 

Als Climbexion ooit is ingevoerd, moet maar eens bestudeerd worden of men voor verschillende 

typen files verschillende status en scope schema's kan implementeren in Climbexion, en of die dan 

gelden in plaats van de status-set satellite/team/baselined of ernaast, en of ze net zo dwingend 

mogen zijn met hun scope en sequence. Immers, we willen met Climbexion “gestructureerd 

samenwerken” mogelijk maken. 

Dan moet ook maar eens gekeken worden of er in Climbexion een opvolger relatie moet worden 

vastgelegd voor interfaces, of dat dit erbuiten geregeld wordt. (opmerking: een interface opvolging 

is geen “succession” de oude en nieuwe interface bestaan een tijd lang naast elkaar, en als alles 

volgens plan verloopt dan verdwijnt de oude op een gegeven moment). In ieder geval kun je 

eventueel een folder gebruiken om elkaar opvolgende interfaces te bundelen. Zeker nu een folder 

een entiteit parameter heeft. 

Certificaat tests 

Nadat een systeem is ingediend voor een certificaat-test mag het betrokken deel van de software 

niet meer gewijzigd worden. Indien de TV slaagt dan geldt dat nog slechts “serieuze fouten” mogen 

worden opgelost, en wel zodanig dat het keurmerk niet beschaamd wordt. Ook hier hebben we te 

maken met status overgangen, en een mogelijke terugkeer naar een voorgaande status. Ik heb geen 

informatie omtrent de precieze regels die gelden, of over regels die de afbakening van de 

gecertificeerde software regelen. Het eist dus nadere studie als Climbexion regels voor deze status 

moet faciliteren. De stadia zijn bijvoorbeeld: “preparation”, “evaluation”, “succeeded”. Een project 

zal dus zeer voorzichtig zijn met wijzigen van gecertificeerde software en hardware, en als een 

wijziging toch nodig is, intern de certificaat test uitvoeren. 

progressie 

Er zijn ook een statussen die zeer zeker niet cyclisch zijn. 

● De status van een (sub)project: de requirements- en voorbereidingsfase, ontwerpfase, 

Pagina: 177 / 230




development fase, integratie fase. 

● De status van het product, of de status van een package zoals vastgesteld door tests. In 

wezen wordt de status bijgehouden door het afvinken van de requirements lijst. Een vooraf 

gedefinieerde mijlpaal wordt bereikt als een patroon van vinken gerealiseerd is. Je kunt tests 

en audits afvinken die doorstaan zijn. Stel een requirement is: het package zal CVBS 

signalen afhandelen. Afvinken kun je dan: het afhandelen van het CVBS signaal is de 

functionele test gepasseerd, de stretch test, de field test, de gebruikers test, of de certificaattest. 

De testers proberen ook nog uit of bepaalde functies testbaar zijn, en vinken ook af of 

een vereiste functie reeds is geïmplementeerd, maar eigenlijk zouden niet zij, maar de 

ontwikkelaars moeten rapporteren, of de functie al klaar is voor testen 

● De status van components en interfaces worden gedurende development fase (waarin 

nieuwbouw en delta processing plaatsvinden) gecontroleerd, door een Pert network of Gantt 

chart bij te houden, van de geplande activiteiten. Deze geven dan de status aan die bereikt is. 

Wat geldt voor document stadia en certificaten geldt ook voor audits en mijlpaal overgangen: je 

mag daarna niet zodanig handelen dat het bereikte stadium een farce wordt. 

Naarmate de software voldoet aan meer requirements groeit ook de regressie test. Dit is één van de 

waarborgen dat een bereikt stadium gehandhaafd blijft. Een andere waarborg is dat bepaalde change 

requests niet meer worden gehonoreerd. Ook de wijze van software wijzigen zal op het laatst 

veranderen: men zal de wijziging minimaliseren, en dus niet gelijktijdig de software 

herstructureren. 

Het bereiken van een mijlpaal is reden voor een borrel. De bijdrage van Climbexion: 

● Mijlpaal documenten kunnen worden opgeslagen als “other-focused” files. 

● Het master project kan een drawer bijhouden waarin overall mijlpalen in geregistreerd staan. 

Het is de vraag of deze mijlpalen werkelijk een snapshot worden in team-drawers. Desalniettemin 

willen de teamleden wel hun feestje. 

2.8.2 Het top package 

De top van een drawer is een bijzonder package. Teams kunnen hun eigen top definiëren, of een top 

kan gemeenschappelijk zijn binnen een master-project. Testers kunnen mogelijk een andere top 

behoeven dan ontwikkelaars, met hun eigen package references. Tool leveranciers behoeven een top 

die toegespitst is op het tool. Kortom: waar teams nauw moeten samenwerken is een 

gemeenschappelijk gedefinieerde topstructuur gewenst, specialisten kunnen behoefte hebben aan 

een afwijkende structuur, en teams kunnen behoefte hebben aan een structuur met privé packages. 

Er zullen dus misschien meerdere top packages nodig zijn. Sommige kunnen uit elkaar voortkomen 

met hulp van import limitations. Bijvoorbeeld testers gebruiken andere import limitations dan 

ontwikkelaars, op een gemeenschappelijk top package. 

Een top package in beheer bij een ander team dat bij ons vrij uitbreidbaar is met references naar 

eigen privé packages wordt niet echt gefaciliteerd. Privé packages kun je aanroepen vanuit eigen 

public packages en dan export limitations gebruiken. 

Opmerking: het top package representeert niet “het product” Er is een speciaal package voor het 

product. 

Van het top package mag mogelijk verwacht worden dat die de toppen van het Build Forest 

Pagina: 178 / 230




definieert, en dat die de cross references naar de global public folders bevat. 

Ik ga er maar vanuit dat het top package geleverd wordt door het master project, en met behulp van 

import en export limitations getrimd wordt voor drawers van subcontractors, en specialisten. 

2.8.3 Locks 

Transactions in databases moeten voldoen aan de ACID regels (zie Wikipedia). 

Lock mechanismen zijn nodig om ongewenste effecten van parallel updates, en van parallel update 

en retrieval te voorkomen. Ze zijn een hulpmiddel om een transaction “geïsoleerd” aan te brengen, 

zodat als een transaction min of meer gelijktijdig met andere transactions, of met gelijktijdige 

requests de database benadert, dat dan voor de andere transactions geldt: of ze zien de database van 

vóór de transaction, of erna. Locks worden vaak gecombineerd met een rollback methode die 

ervoor zorgt dat transactions atomair zijn zodat alle wijzigingen van een transaction worden 

aangebracht in de database, of geen één van alle. 

Expliciete locks zijn vaak te vermijden: 

● Satellites bijvoorbeeld, hebben over het algemeen één enkele gebruiker, die met één tool in 

één process de database benaderd. Haar of zijn opdrachten komen niet gelijktijdig, maar 

achter elkaar: er zijn geen effecten van parallel update 

● In een drawer wordt niets overschreven, maar alles wordt in een course geplaatst. Als de 

drawer wordt benaderd voor louter retrieval, op de tip, dan wordt eerst de timestamp gelezen 

van de laatste correct geëindigde transaction, en die wordt als snapshot gebruikt. 

Het mechanisme van de transfer-drawer zorgt dat envelope transfers in een rij gezet worden, en dan 

sequentieel afgehandeld. Dit is het meest basale principe van locking: een envelope transfer is in 

lock totdat hij aan de beurt is in de rij waarin hij staat. In een database zijn vaak meer verfijnde 

methoden gerealiseerd, waarbij verschillende transactions parallel kunnen worden afgehandeld, 

maar die zijn voor een repository mogelijk niet altijd nodig. 

Naast dergelijke interne locking, die vaak niet langer duurt dan enkele seconden, is er in veel 

revision control software nog een locking mechanisme dat uren of zelfs dagen kan duren, en die 

niet alleen interne processen blokkeert, maar ook mensen die iets willen wijzigen. Een 

geblokkeerde file kun je niet wijzigen, althans je kunt de wijziging niet in de betreffende drawer 

plaatsen. Behalve natuurlijk als je zelf de blokkade hebt ingesteld. Als je een wijziging wilt 

doorvoeren op een aantal files, dan moet je wachten tot er geen meer geblokkeerd is. Parallel 

updates en dus merging worden zo voorkomen, maar mensen kunnen slechts wachten tot de lock 

voorbij is. Bord en kaartspelen zijn speciaal uitgevonden om dergelijke wachttijden door te komen. 

Climbexion implementeert dit niet, maar gaat ervan uit dat wijzigingen gebaseerd op snapshot A, 

gemakkelijk –, bijna automatisch -, gewijzigd kunnen worden in wijzigingen gebaseerd op 

snapshot B, zodat je niet op elkaar hoeft te wachten, maar alvast aan het werk kunt op een 

voorlopig snapshot. Langdurende locking is dus normaal niet nodig, ten koste van het meer keer 

aanbrengen van een wijziging, hetzij door merging, hetzij met de hand. We gaan er dus van uit dat 

alleen de eerste keer wijzigen langdurig werk is. En dat dit niet alleen geldt als een merge 

programma kan worden gebruikt, maar ook als je de wijzigingen met de hand moet integreren in 

andere version. 

Normaal zal de eis dat bij een transfer zowel de base version als de nieuwe version worden vermeld 

Pagina: 179 / 230




in de envelope, samen met een notificatie als files op meerdere plaatsen onderhanden zijn, en een 

eventuele onderling overleg, voldoende zijn om te voorkomen dat parallel updates de consistentie 

verstoren. Climbexion controleert dan of de base version de tip is van de course die moet worden 

uitgebreid, en weigert envelopes als er geen match is met een uit te breiden tip. 

In ons team waren er bepaalde files die zeer frequent door iedereen gewijzigd werden. Dan viel het 

niet altijd mee om een envelope over te dragen. Het kon voorkomen dat anderen je steeds voor 

waren, en je een aantal malen moest instellen op een nieuwe base, (en een build uitvoeren ter 

verificatie). Ik meen dat zo'n situatie, waarbij je steeds opnieuw moet beginnen maar nooit het eind 

haalt, “starvation” (hongerdood) wordt genoemd. Een file die transfer competitie uitlokt kunnen we 

een “choke-point” noemen. De platform cd file, en de cd file van de platform diversity component 

zijn voorbeelden. In de beschrijving van dians is er ook één bedacht. In de team-drawer zijn het de 

files met een excessieve lengte van de version course. Tussen de tien files met een de langste 

course zullen ongetwijfeld enige choke-points zitten. 

Starvation is een mooie term, maar eigenlijk was het zo dat je je ei maar niet kwijt kon. 

Ik ben natuurlijk geneigd om verwijtend naar de architecten te kijken, die niet een structuur 

bedacht hebben waarin dit soort files vermeden wordt. Maar aan de andere kant is het natuurlijk 

een uitdaging voor een tool-maker om hier een oplossing te bedenken. Zelfs als architecten een 

oplossing weten voor zo'n probleem, dan moet het zich waarschijnlijk eerst manifesteren, en is er 

een periode waarin Climbexion kan schitteren met een oplossing. 

Het blijft laveren tussen “ontwerpen is vooruit zien” en “de mensheid lijdt het meest aan 't lijden 

dat men vreest...”, tussen bedenken en bekijken, tussen rationalisme en fenomenologie. In software 

ontwikkeling is er mogelijk een tendens om vooral te voorkomen, want de gelegenheid om te 

reageren op bedenkelijke fenomenen die zich in de software voordoen is er te vaak niet. Maar 

voorkomen van zaken die later geen probleem blijken te zijn levert zelf ook rare constructies op. In 

ieder geval voor de geschetste starvation probleem geldt dat het niet voorkomen werd. 

Anti-starvation. 

In zo'n situatie zou een lock op de file wel eens gewenst kunnen zijn. Als meerderen een lock zetten 

op een file, met vermelding van hun envelope, dan ontstaat er in feite een queue, een vooraf 

bepaalde volgorde, waarin de envelopes mogen worden overgedragen. Als je envelope aan de beurt 

is baseer je de wijzigingen op het laatste snapshot, pleeg je de builds en geef je de envelope vrij 

voor transfer. Het is een oplossing die nieuwe problemen creëert: wat als de eigenaar van een 

envelope inmiddels in een vergadering zit of zo als zijn envelope aan de beurt is, dan houdt die de 

hele queue op. Er is dus waarschijnlijk extra communicatie en queue management nodig. Sommige 

envelopes zullen in meerdere queues zitten, dan kan de ene queue de andere ophouden, en zo zijn er 

nieuwe problemen die om een oplossing vragen. Ik denk dat we dit maar niet te snel moeten doen: 

locks op transactions, die interacties plegen met mensen. 

Zo'n probleem beschrijving als hierboven is wel ongeveer een introductie op een inleiding. 

De manier waarop dergelijke locks gedaan worden in databases (in twee fasen) is bijvoorbeeld 

beschreven in: 

C.P. Eswaran, J.N. Gray, R.A. Lorie, and I.L. Traiger: “The Notions of Consistency and Predicate 

Pagina: 180 / 230




Locks in a Database System ”; Communications of the ACM; November 1976 Volume 19 Number 

11 p 624-632. (In 1976 was de term ACID nog niet bedacht) 

De queues die ik gebruik zijn afwijkend ten opzichte van “The Notions of Consistency and 

Predicate Locks in a Database System ”. 

● In “The Notions ...” betekent de opdracht “lock” in een thread op een queue waarin 

voorgangers zitten ogenblikkelijk: “kom in een “wait state” totdat de voorgangers uit de 

queue zijn verdwenen, en vervolg dan de thread”. Ik ga uit van messages met een callback 

procedure, die aangeroepen wordt als de entry in de queue aan de beurt is. De thread die de 

message stuurt gaat gewoon door na het sturen. 

● In “The Notions ...” wordt expliciet de opdracht “unlock” gegeven, in de door mij geschetste 

methode betekent “return” van de callback procedure: “message verlaat de queue”. 

● Als je kiest voor een queue/lock per element, en je wijzigt de version, de name, en de folder 

reference, dan betekent dit in “the Notions ...” één lock voor alle wijzigingen, voor de 

message queues kan iedere wijziging een message zijn. 

● “Mijn” message queues zijn natuurlijk niet van mij. Ze zijn bijvoorbeeld beschreven in 1.4.8 

in de sectie “Pumps en pump engines”. Het is wel zo, dat ze identificeerbaar zijn met een 

willekeurige name (de kin id bijvoorbeeld). De meesten worden automatisch gecreëerd als 

de eerste message wordt toegevoegd, en verdwijnen automatisch als de laatste message is 

verwerkt. Maar sommigen worden expliciet gecreëerd, en vervallen expliciet, en mogen in 

de tussentijd messages bevatten of leeg zijn. 

● Een kin id wordt geacht uniek te zijn binnen een package. Als je hem gebruikt als 

queue/lock name dat betekent dit mogelijk een kleine vergroving van de granulatie van de 

queue/lock, als de kin id ook in gebruik is in een ander package. Het mogelijke parallellisme 

wordt nauwelijks aangetast. 

Nu er courses worden bijgehouden is het voor de isolation rule nodig dat als twee envelopes twee 

dezelfde files wijzigen, dat óf de ene (direct of indirect) gebaseerd is op de tips die de ander 

achterlaat óf omgekeerd, maar wat niet mag is dat de ene file eindigt met de tip van envelope één en 

de ander met een tip van envelope twee. De startfasen van de overdracht van aangeboden envelopes 

kunnen daarom het best één voor één af gehandeld worden, bijvoorbeeld met behulp van een 

“startfase queue”. De startfase (de locking fase) start nadat een envelope is aangeboden voor 

overdracht, zodra die aan de beurt is in de queue. In de startfase worden de messages gestuurd naar 

element queues, met onder meer references naar de envelope en de callback procedure. De 

onderlinge volgorde van de envelopes in de startfase queue wordt ook de onderlinge volgorde in de 

queues van gemeenschappelijke elements, en wordt ook de onderlinge volgorde waarin ze de 

courses van de gemeenschappelijke elements uitbreiden. Daarom is de sequencing in de startfase 

queue reeds voldoende is: het vrijgeven van messages in element queues hoeft niet per se te 

wachten tot fase twee. 

Het is natuurlijk wel zo dat er ook nog een changeset moet worden bijgehouden. Een lege changeset 

zou je meteen in het begin van de startfase op de tip van het transaction element kunnen plaatsen, 

zodat een volgende transactie er ook één aan kan toevoegen. De invulling vindt dan plaats als de 

elements worden bijgewerkt. 

De locks die worden uitgevoerd zijn locks (en dus updates van queues) op kin id's (eventueel meer 

verfijnd: locks op de courses van elements). Er is dus in principe een queue per element (of per 

course van een element), voor de elements die op een zekere tijd betrokken zijn bij een overdracht. 

Pagina: 181 / 230




Er komt of er is een moment waarop er voor een envelope geen voorgangers zijn in een element 

queue. Dan moet soms een nieuw base/labored paar worden gemaakt door de indiener. Een element 

waarvoor geen nieuw base/labored paar nodig is wordt vrijgegeven zodra er geen voorganger is in 

de queue, en de tip van de betreffende course is bijgewerkt. Een element waarvoor een nieuwe 

labored version moet worden gemaakt wordt pas bijgewerkt op de tip en vrijgegeven bij het 

beëindigen van de overdracht, nadat is merge is uitgevoerd, merge fouten verholpen, en builds 

foutloos zijn. Dit vrijgeven komt erop neer dat de message de element queue verlaat, zodat zijn 

eventuele opvolger aan de beurt kan komen. 

Over het algemeen zijn database transactions niet vrij van deadlocks. Deadlocks kunnen 

voorkomen als een transaction aan de beurt moet zijn in meer dan één queue tegelijk. Per element, 

en dus per queue is er één actie, zodra de envelope aan de beurt is. Combinaties van queues waarin 

de envelope aan de beurt moet zijn voordat iets mag gebeuren worden niet gebruikt, en zo'n 

combinatie is wel nodig voor een deadlock. 

Zonder startfase queue, had de transaction moeten wachten tot ze in alle element queues aan de 

beurt zou zijn, voordat tips konden worden bijgewerkt. Omdat dan niet voorkomen wordt dat de éne 

envelope aan de beurt is in de éne gedeelde queue en de andere in een andere gedeelde queue is 

deze methode, zonder verdere maatregelen, niet vrij van deadlocks. 

Enige aandacht is vereist voor het aanbrengen van tips in courses. De timestamps van course items 

bestaan mogelijk uit de datum/tijd van de start van hun envelope overdracht, en een event 

aanduiding, zodat deze altijd vroeger zijn dan de timestamp van de start van een volgende envelope. 

Het geschetste algoritme kan enigszins uitgebreid worden. In het begin, voordat enige version is 

overgedragen kan de overdracht “gratis” (zonder rollback) gecanceld worden. Het zou een 

overdrachtsoptie kunnen zijn: als merge zou moeten plaatsvinden, cancel dan de overdracht, want 

dan probeer ik het later nog eens, nadat ik de satellite heb gesynchroniseerd met de tip van de 

transfer-drawer. (dit is de starvation situatie). Nadat hierop is gecontroleerd, en er geen problemen 

zijn, kan een changeset worden geïnitieerd, en kunnen de betreffend queues worden worden 

uitgebreid. De voorganger in de element queues moet hiervoor geïnspecteerd kunnen worden: 

immers de labored version die eruit voortkomt moet bekend zijn en overeenstemmen met een base 

version in de huidige envelope. 

De methode kent als beperking dat uitsluitend die files mogen worden gewijzigd waarvan 

Climbexion aangeeft dat een nieuwe labored version moet worden gemaakt in de envelope. Als er 

buiten de betreffende files moet worden gewijzigd, moet de overdracht worden gecanceld en moet 

een nieuwe overdracht worden voorbereid. 

Als het wijzigen van de drawer begonnen is, en er moet een merge plaatsvinden, dan is het toch wel 

een plicht om de overdracht tot een goed einde te brengen. 

Als je dan toch besluit om de overdracht te cancelen, dan betekent dit: 

● Eerst moeten ook alle erop volgende –, niet voltooide –, transactions tijdelijk gecanceld 

worden. Het is denkbaar dat dit verfijnd kan worden: transactions die een element delen met 

een uitgeschoten voorganger, hun transaction moet ook gecanceld worden, maar wel 

tijdelijk. Dit is een soort olievlek effect. 

● Dan vindt rollback plaats. Dit herstel van de drawer is een soort transaction zonder 

envelope. In plaats van rollback stel ik het volgende voor: Elke tips die reeds was 

bijgewerkt door de uitgeschoten envelopes moeten uitgebreid worden door het juiste 

voorgaande course item opnieuw aan te brengen. Dergelijk herstel laat dus “littekens” 

Pagina: 182 / 230




achter in de drawer, die later gebruikt kunnen worden bij evaluaties van 

overdrachtsprocedures. Dit is niet zuiver “atomair”, en is een herziening van het “duration” 

principe qua ACID. 

● Daarna moeten alle tijdelijk uitgeschoten envelopes opnieuw overgedragen worden. 

Het blijft natuurlijk een probleem dat menselijke interactie is vereist bij de uitvoering van de 

transaction, en dat ze duurt totdat de indiener tevreden is met alle merge, rework en rebuild 

resultaten. De locks op de aan te passen elements duren daardoor lang, zelfs als de mens 

ogenblikkelijk beschikbaar is. 

Een optie kan zijn om bij de overdracht waarbij een merge moet plaatsvinden, om dan een niet 

interactieve merge unattended uit te laten voeren door de overdrachtssoftware. Alleen bij merge 

conflicten (of build errors) wordt overgegaan op een interactieve modus, of wordt de overdracht 

gecanceld. Indien gekozen wordt voor cancel, kunnen base versions in envelopes die na de 

uitgeschoten envelope komen hun match met een tip verliezen, waardoor ook deze envelopes een 

probleem hebben. Mocht deze methode over het algemeen goed verlopen, dan zou je kunnen 

besluiten om de laatste synchronisatie, die nu plaatsvindt vóór de overdracht, te laten plaatsvinden 

tijdens de overdracht. 

Enige aandacht is vereist voor het uitvoeren van een build. Het synchroniseren van satellite en 

working-tree, met de transfer drawer is hier geen trivialiteit. 

Voor merge is het voldoende als een envelope geen voorganger heeft in de betreffende element 

queue. Voor het synchroniseren van een tree ten behoeve van build moeten de overdrachten van alle 

voorgaande envelopes voltooid zijn, dus de envelope zelf mag geen voorgangers hebben in een 

“synchronize queue”. 

De build zelf mag pas plaatsvinden als alle merge en synchronisatie klaar is in de betreffende tree. 

Niet alle transactions vereisen een build,en deze transactions verlaten de synchronize queue terwijl 

ze mogelijk nog voorgangers hebben. Het verlaten van de synchronize queue betekent het einde 

van de transaction en mag plaatsvinden als alle element queues zijn verlaten, en alle tips zijn 

bijgewerkt. 

Files die niet met een merge tool verenigd kunnen worden (bijvoorbeeld: documenten, 

spreadsheets, plaatjes), kun je overdragen in een envelope met de mogelijkheid van cancel in het 

begin. Als deze optie niet gekozen wordt dan geldt voor een dergelijke file dat ze alleen handmatig 

gewijzigd kan worden tijdens een transfer, dus niet unattended: er is immers geen merge 

programma. Ook geldt waarschijnlijk dat er op het eind geen build of extra verificatie nodig is. 

Meestal zijn dergelijke files niet de files die starvation of queuing veroorzaken. Het enige bezwaar 

met de interactieve methode zit hem in het verlaten van de synchronize queue als de transaction 

voorbij is, hierdoor kan een handmatige methode het uitvoeren van builds ernstig vertragen. 

Er zijn drie basis overdrachtsopties: 

● Eventueel cancelen in fase één (mogelijk starvation) 

● Interactieve merge, rework en build. (mogelijk langdurig ophouden van enkele queues) 

● Niet interactieve merge en build en cancel bij conflicten en fouten (mogelijk moeten 

envelopes opnieuw worden aangebracht, met alle problemen van dien wat betreft tip/base 

matchen). 

Deze opties hebben zo hun nadelen. Je kunt dit moeilijk “schitteren met een oplossing” noemen. 

Nog enige opmerkingen: 

Pagina: 183 / 230




● De messages in een queue kunnen het best in dezelfde thread afgehandeld worden, ze 

moeten immers toch successievelijk afgehandeld worden. 

● De startfase queue, zou mogelijk met een lage prioriteit kunnen worden afgehandeld in zijn 

eigen thread. Dat houdt de element queues zo klein mogelijk. Misschien kan een element 

queue zelfs vermeden worden als er nog geen queue is en en de base komt overeen met de 

tip. De betreffende callback procedure kun je dan direct aan roepen in de startfase 

procedure. 

● Nu iedere element queue een eigen thread heeft moet ervoor worden gezorgd, dat de 

wijzigingen op de changeset geordend verlopen. Dit kan bijvoorbeeld gebeuren met een 

queue als de andere, of met een synchronisatie primitieve als een semaphore, critical 

section , mutex en dergelijke. 

● Een “wait state” kan plaatsvinden in de callback procedure ten behoeve van interactieve of 

unattended acties, totdat de envelope is bijgewerkt met het juiste base labored paar (voor 

element queues). Ook in de procedure van de synchronize queue vindt een “wait state“ 

plaats, totdat de transaction mag eindigen. 

● Normaal in database transactions is er binnen een transaction een samenhang die moet 

worden bewaakt, waardoor er afhankelijkheden zijn tussen de database opdrachten. Bij 

software repositories wordt de samenhang bewaakt buiten de transaction, door builds en 

tests, en QA software, vandaar dat we met de geschetste queues kunnen werken, en ieder 

element afzonderlijk kunnen toevoegen. 

Ik heb bedacht: Starvation kan altijd nog vermeden worden door één persoon aan te wijzen die een 

file mag wijzigen: de owner. 

Maar toen herinnerde ik mij het eerste project in 2002, waarbij de eerste digitale TV werd 

ontwikkeld. Er werden nogal wat programmeurs ingehuurd, die voor het eerst te maken kregen met 

tv's en hun software. De platform software werd in eerste instantie overgenomen uit analoge tv's en 

heel of half gelukte hybride voorgangers, en dan aangepast aan de nieuwe tv chip. Dit werd gedaan 

door het ingehuurde team. Ieder kreeg een een paar componenten toegewezen, en was daarvan 

gedurende de looptijd van het eerste reference project de component owner. 

Toen al manifesteerden zich de files die zeer frequent gewijzigd moeten worden. De componenten 

waartoe die files behoorden waren de eersten zonder owner: iedereen moest zelf de files aanpassen 

als de ontwikkeling van zijn eigen componenten dat eiste. Het werk dat zich voordien ophoopte bij 

de owner frustreerde de voortgang, bracht iedereen tot wanhoop, en de owner misschien wel tot 

waanzin. 

2.8.4 Notifications 

Bepaalde gebeurtenissen in het revision control system kunnen leiden tot notificaties voor de 

betrokkenen. Dit gebeurt traditioneel door ze een email te sturen. Het plaatsen van een package in 

een export-drawer is aanleiding om de integrators van andere teams een email te sturen. De Transfer 

van een envelope kan een trigger zijn om de build manager een email te sturen. De implementation 

van een envelope waarmee een nieuwe baseline van een package beschikbaar komt is een reden om 

mails te sturen naar de satellite owners, enzovoort. 

De notificaties waarop iemand zich kan abonneren, zijn mogelijk afhankelijk van security regels. 

Pagina: 184 / 230




Overigens kun je altijd de status van het revision control system bekijken: door dit geregeld te doen 

heb je eigenlijk geen notificatie nodig, en als je een faciliteit hebt die automatisch en regelmatig 

polst, dan is er mogelijk een eenvoudige implementatie. Dit is in ieder geval een mogelijkheid voor 

een eerste aanzet van Climbexion. Ieder is dan autonoom en bepaalt zelf welke notificaties worden 

gepolst. In sommige bestaande systemen worden RSS-feeds gebruikt. 

Op een gegeven moment moet er ook maar eens gekeken worden of er mogelijk ook notificaties 

zijn waarvan anderen vinden dat iemand ze moet ontvangen, en die dan rücksichtslos instellen. 

Behalve het notificeren zouden er al dan niet automatisch scripts gestart kunnen worden om de 

notificatie af te handelen. Bijvoorbeeld als er een nieuwe baseline beschikbaar komt van een 

geabonneerd package, dan worden automatisch een import area, een satellite en een envelope 

voorbereid voor het inlijven van de baseline in de team-drawer. 

2.8.5 Pool operaties 

We kunnen het ons gemakkelijk maken en ervoor kiezen om iedere drawer te voorzien van een 

location voor alle denkbare pools. Voor de gemiddelde gebruiker is dat waarschijnlijk het 

gemakkelijkst. Het betekent wel dat de objecten in een pool vaak gekopieerd moeten worden. Zoek 

je een optimum, waarbij zo min mogelijk wordt gekopieerd, de security nog acceptabel is, en 

waarbij er niet teveel garbage verschijnt in de centrale pools, dan is er mogelijk ook nog wat plezier 

voor analisten en ontwerpers, om na te gaan hoe je en dergelijk complex opzet. 

Ook anderszins kunnen we het ons gemakkelijk maken met de regel: er zijn geen lokale pools. Er is 

per package slechts één kin pool en één version pool. Merk op dat hierbij niet geldt dat een drawer 

verwijst naar de location van de package pools, maar dat iedere package reference verwijst naar de 

pools van het package. Met een dergelijke structuur benaderen we de eenvoud van de vorige 

oplossing, maar in ieder geval ten koste van de security van export limitations, en van 

beschikbaarheid en mogelijk performance als er netwerk problemen zijn. In deze situatie, zo is de 

verwachting, zijn overdrachten zeer efficiënt. Er hoeft immers niet met versions te worden gesleept 

(behalve om working-trees en info-trees bij te houden). 

Deze twee uitersten zijn mogelijke opties. Maar we zullen toch maar bedenken hoe we moeten 

handelen met pools in locations die niet strikt gebonden zijn aan drawers of packages. 

Package pools 

Creëren, splitsen, samenstellen 

Pools zijn opgeslagen in locations. Een drawer verwijst naar de (ene) location waarin de pools van 

zijn packages staan. Dit is geen statische en eeuwige situatie. Locations kunnen ontstaan en 

beëindigd worden, waardoor de eigenaars de verwijzing van hun drawers moeten aanpassen. Een 

package moet geïntroduceerd worden in een location als het package opduikt in één van de drawers 

die naar de location verwijzen, en het package mag verwijderd worden, als de gezamenlijke drawers 

die overblijven op een location het package niet gebruiken. 

Er kunnen redenen zijn om locations te splitsen, als dit vereist wordt door security, groei, splitsen 

van teams, thuiswerken, of intensivering van bepaalde activiteiten. Bijvoorbeeld: binnen een 

subproject gaan een aantal mensen samenwerken aan een nieuw onderdeel van een package, en 

Pagina: 185 / 230




creëren een sub-team-drawer, en een gemeenschappelijke location voor center en satellites. Deze 

location splitst zich feitelijk af van de center location van het team. 

Er kunnen redenen zijn om locations samen te stellen. Beëindigde projects worden bijvoorbeeld 

toegevoegd aan de historische location. Er kan besloten worden om subprojects samen te stellen tot 

een one-roof project. Dan kan het efficiënt zijn om pools te combineren. 

Creëren splitsen en samenstellen kan op de volgende manier: 

● Een pool location moet eerst zijn gecreëerd voordat een drawer ernaar kan verwijzen. Dit 

komt vermoedelijk neer op een simpele creatie van een folder en wat lege files in een file 

system. 

● We gaan ervan uit dat een drawer de location kent van zijn pools, Als van een drawer zijn 

verwijzing naar een location wijzigt dan behelst de wijziging een update van de pools van de 

nieuwe location. 

● We gaan ervan uit dat een location en al zijn drawers bij tijd en wijle gezamenlijk 

toegankelijk zijn om “garbage collection” uit te voeren op de pools. Hierbij is het uiteraard 

vereist dat de lijst van drawers compleet is. 

Bijwerken van pools 

Er kunnen alleen elements worden toegevoegd aan package pools. (Met uitzondering van een 

garbage collection process waarbij ook elements kunnen worden verwijderd). Kin pools worden 

bijgewerkt zodra een nieuwe kin verschijnt in een drawer of envelope, en de version pool wordt 

bijgewerkt zodra een nieuwe version verschijnt in een drawer of envelope. 

De centrale pool wordt bijgewerkt bij iedere transfer van de ene pool naar de andere. Attribute 

wijzigingen kunnen een aanleiding zijn voor zo'n transfer. Regelmatig moet gecontroleerd worden 

of de attributes die centraal zijn opgeslagen recenter zijn dan de attributes in de pool, en regelmatig 

moet gecontroleerd worden of de attributes in working-tree of info-tree niet verouderd zijn ten 

opzichte van de pool. 

Envelope pools 

Deze pools horen bij een constellation, bij de center-drawer van de constellation. Als het blijft bij 

deze constatering, dan heeft dit de volgende consequentie: Zodra een version, of een nieuwe kin, 

wordt vermeld in de envelope, dan moet ook de betreffende package pool bijgewerkt worden. Dit 

zou kunnen betekenen dat de version pools van het center “vervuild” worden met allerlei voorlopige 

dingen die in de satellite ontstaan. 

Voorlopig houd ik het er maar op dat een personal computer, waarop satellites van een constellation 

voorkomen, een envelope pool heeft. De envelopes in deze pool en hun inhoud, zijn nog niet 

“gepubliceerd”. Dat gebeurt pas als ze verhuizen naar de constellation pool. In de status “preparing΅ 

kan een envelope dus voorkomen in de pc pool, in de constellation pool, of in beiden. 

Pool opdrachten voor envelopes: 

● create: nieuw in een satellite pool 

● publish: transfer naar de constellation pool. Dit kan op onderdelen, zodat bijvoorbeeld eerst 

base versions gepubliceerd zijn, en labored versions pas als de transfer van software 

plaatsvindt van satellite naar transfer-drawer, of naar center-drawer. 

Pagina: 186 / 230




● rework: copy naar de satellite pool 

In eenvoudige situaties is er slechts de constellation pool, maar geen PC gerelateerde pool en is er 

slechts de pool opdracht “create”. 

Pools voor other-focused files 

Deze pools horen bij een project, maar ook bij een package. Locations waarin deze pools kunnen 

voorkomen behoren tot een subproject. Het uitwisselen van other-focused files, vindt plaats binnen 

het master-project, maar wordt niet verwacht als sister-projects onderling gegevens uitwisselen. 

Pools op een PC zijn dan ook meestal voor één project, waar version pools bijvoorbeeld gebruikt 

kunnen worden voor meerdere projects. 

Misschien is het om te beginnen raadzaam om je te beperken tot snapshot-focused files en alleen 

“own-drawer-focused” filestrings te implementeren. 

Files die we niet willen overdragen vanuit een satellite zouden moeten refereren aan een tag die 

gebonden is aan die satellite, en die niet wordt overgedragen. Voorbeeld: een opgeslagen build 

result kan zijn vervaardigd voor een tag in de center-drawer. En daarna gedistribueerd naar 

satellites. Iemand maak voor zichzelf een build result op hetzelfde snapshot, waarin bijvoorbeeld 

enige logging wordt geactiveerd. Deze version mag niet gedistribueerd worden, dus zou de version 

niet mogen worden gemaakt op dezelfde tag, er is dus een nieuwe file nodig, refererend naar een 

nieuwe tag. 

Een probleem kan ontstaan als een overdracht heeft plaatsgevonden van de éne drawer naar de 

andere, bij drawers zonder gemeenschappelijke pool. Als daarna een version wordt vervaardigd 

voor een file in de file-string, of als een file ontstaat in de file-string, en de tag is reeds 

overgedragen dan komt de version of de file niet automatisch beschikbaar in de drawer die verwijst 

naar een andere pool location. 

Versions die wel automatisch zijn doorgevoerd moeten daarna nog hun weg vinden naar (virtual) 

info-tree of working-tree. 

Wijzigingen op other-focused file-strings worden doorgevoerd in een centrale pool, controle op 

wijzigingen kan dan gelaagd plaatsvinden, eerst wordt bepaald of de centrale pool gewijzigd is 

sinds de vorige keer, zo ja dan wordt bepaald of een geabonneerde file-string gewijzigd is, tenslotte 

of er nieuwe files of versions zijn. Dit kan periodiek unattended plaatsvinden, maar ook op het 

moment dat een (virtuele) info-tree of working-tree wordt gemaakt. De centrale pool bij wijzigingen 

in een center-drawer die doorgevoerd moeten worden in satellites is gerelateerd aan die centerdrawer. 

Bij wijzigingen die geëxporteerd worden is de centrale pool gerelateerd aan de exportdrawer. 

Pool operaties: 

● create: in een location, met eventuele verwijzing naar de centrale location. 

● Synchronize: indien een drawer ernaar gaat verwijzen door een location change wordt 

bepaald welke file-strings, files en versions erin opgenomen moeten worden en uit de 

oorspronkelijke pool moeten worden gekopieerd. 

● Synchronize: om de pool periodiek, of incidenteel, bij te werken vanuit de centrale location. 

Tot nu toe spreken we over pool, alsof de verzameling filestrings vrij ongestructureerd is. Maar het 

Pagina: 187 / 230




ziet ernaar uit dat de pool stevig gestructureerd kan zijn, en een tree structuur zoals een drawer kan 

hebben, zodat derived files in andere folders komen dan test-reports, die weer ergens anders staan 

als baseline-documents. Dat zou betekenen ze in wezen een drawer structuur kunnen hebben, of dat 

de drawers zelf de filestrings bevatten. Dan is het ook nog maar de vraag of de filestring reference 

blijft bestaan, zodat er onderscheid is tussen het raadplegen of gebruiken van de data via de 

reference en het onderhouden ervan, rechtstreeks in de filestrings. Ik moet daar nog maar eens goed 

over nadenken. 

2.8.6 Importeren, Exporteren 

Eén revision control system voor allen is onhaalbaar, zelf een team moet soms opereren met 

meerdere systemen: één per klant. Zelfs is het zo dat verschillende teams verschillende merken 

revision control systems gebruiken. Wat ik hier heb gespecificeerd is nu niet bepaald compatibel 

met andere systemen. 

1. Binnen Climbexion. 

Snapshots van drawers en packages kunnen worden geëxporteerd en geïmporteerd met references 

naar kins, en versions, en met overige attributes. References naar envelopes worden niet 

geëxporteerd. Gegeven de pools behoeven versions en kins niet “in stream” geïmporteerd of 

geëxporteerd te worden: ze worden gekopieerd als ze nodig zijn in een work of info-tree, of in een 

lokale subpool. Een snapshot van een drawer of een package zoals dat in de drawer is opgeslagen 

wordt als een stream verzonden en ontvangen. 

Uiteraard kunnen er import en export limitations gelden, of speciale regels. Die moeten natuurlijk in 

acht worden genomen. 

Voor adopt merge geldt bijvoorbeeld de volgende query: We selecteren package S, export 

limitations gelden niet, we willen geen mutaties van name course en folder reference course tenzij 

het element nieuw binnenkomt, we hoeven geen other-focused files, geen classification-sets en 

classification-anchors, geen inner-reach van test folders. We willen een filetype controle op 

compatibiliteit, niet slechts als waarschuwing, nee, incompatible files moeten echt niet 

geïmporteerd worden. Ook willen we geen event items die aangeven dat een element niet meer 

bestaat. 

Exact copy. 

Gegeven bijvoorbeeld: laatste overgenomen snapshot tag_a. Het over te nemen snapshot is 

tag_b. De source drawer is in beide gevallen drawer S, de destination drawer is in beide 

gevallen drawer D. We gaan er even van uit dat export limitations niet gerealiseerd zijn 

middels een aparte drawer. De import/export limitations nu op het moment van query ild, 

els. 

De gang van zaken kan als volgt zijn: destination drawer D vraagt drawer S om de 

betreffende set event items: 

Query snapshot=tag-b, importLimitations=ild 

De source drawer S bepaalt: 

export = ild (els (snapshot(drawer(S), tag_b))) 

en stuurt export over naar D in de vorm van een set nieuwe event items. De destination 

drawer plaatst een subset van export als succession in zijn tip. De verzameling event 

items: 

Pagina: 188 / 230




exclude = intersection (export ,snapshot(drawer(D), tip)) 

wordt niet aan de tip toegevoegd, maar slechts de set 

changeset = export\exclude. 

De destination drawer D controleert of er nieuwe kins en nieuwe versions in zijn (lokale) 

pools moeten worden geplaatst en nieuwe elements in zijn drawer. De grootste compactheid 

wordt waarschijnlijk bereikt als er een diff programma bestaat voor een filetype. Dan 

behoeven voor de betreffende tag-b versions slechts de delta's te worden verstuurd ten 

opzichte van tag-a versions. De query wordt nu: 

Query snapshot=tag-b, importLimitations=ild,lastSnapshot=tag-a 

De drawer D software zoekt voor iedere nieuwe version de id van de tag-a version, en 

maakt de delta's. Er is misschien een samenloop van omstandigheden waardoor deze version 

in de pool van D niet voorkomt dan wordt de volledige version gekopieerd. Delta's of 

volledige versions bevatten uiteraard alle metadata om de nieuwe version lokaal in de pool 

te zetten, inclusief zijn originele valid time timestamp. Een error log vermeldt de filetype 

conflicten en incompatibiliteiten. Een optie bepaalt of een error een uitschieter is, of moet 

worden geaccepteerd. De subset courses in D die hierdoor gewijzigd wordt wordt volledig 

bepaald door de events die in de set export worden overgestuurd. 

Een volledige vervanging eist dat alle courses worden beëindigd, waarvan de tip behoort tot 

de set elements: 

elements(snapshot(drawer(D),tip))\elements(export). 

Als een package U moet worden vervangen dan geldt dat alle courses moeten worden 

beëindigd waarvan de tip behoort tot de set: elements 

elements(snapshot(package(D,U),tip))\elements(export) 

Uiteraard moet export dan als volgt tot stand zijn gekomen: 

export = ild(els(snapshot(package(S,U),tag_b))). 

In principe kun je werken op een gehele drawer of op een package met 3 soorten 

limitations: 

● import limitations van Destiny: ild. Dit kan een combinatie zijn van vaste drawer en 

package gerelateerde limitations en van adhoc limitations. 

● export limitations van Source: els. 

● replacement limitations van Destiny: rld. Dit is de verzameling courses die vervangen 

moeten worden door export, of anders beëindigd. We nemen aan dat geldt: 

elements (ild (snapshot(f(D),tip))) ⊆ elements (rld 

(snapshot(f(D),tip))) 

We gaan er bij deze methode vanuit dat sinds de vorige keer er wijzigingen kunnen zijn 

geweest in els en ild. Als limitations geen rol spelen, of als ze niet gewijzigd zijn, kunnen 

we uitgaan van de course van de changesets in de source drawer, de wijzigingen die "live" 

zijn in de reeks changesets van tag-a naar tag-b kunnen worden vastgesteld en vormen 

de export, eventueel na toepassing van els en ild. 

Adopt merge. 

De source drawer is een merge-import-drawer, destination is een satellite van de teamdrawer. 

original is het snapshot waarmee de vorige keer een exact copy is uitgevoerd 

vanuit een sister-project in de merge-import-drawer. neighbor is de tip van deze drawer, 

die ontstaan is uit een recente exact copy, mogelijk gevolgd door een aantal “undo” 

changesets. Als je gaat kijken in de merge-import-drawer dan zie je daar de volgende 

Pagina: 189 / 230




sequentie van tags: …, Rn (baseline tag), Un(undo tag), Rn+1(baseline tag) , Un+1(undo tag). 

Rn specificeert het original, en Un+1 specificeert de neighbor. 

Destination drawer is een team-drawer satellite, waarin met exact copy de tip of tip-tag van 

een team-drawer is geplaatst: dit is een snapshot dat de base omvat. Mogelijk geldt er een 

import limitation: il, die geldt voor het original, en de neighbor en de base. 

Er is natuurlijk een kans dat il gewijzigd is sinds Rn werd geïmporteerd, dan geldt dat Rn 

opnieuw moet worden geïmporteerd, en krijg je bijvoorbeeld de volgende sequentie van tags 

…, Rn (baseline tag snapshot geïmporteerd met il_oud), Un(undo tag), Rn(baseline tag, 

snapshot geïmporteerd met il), Rn+1(baseline tag geselecteerd met il), Un+1(undo tag). 

Nu moet de meest recente tag Rn gekozen worden om original te specificeren. We 

nemen aan dat tussen dit en het sister-project geen export limitations gelden, anders zou je 

ook nog moeten checken of die een wijziging op Rn teweeg zouden brengen. We zijn 

natuurlijk slim en gebruiken voor het importeren uit het sister-project de merge-import 

limitation mil. Als relatie (ilt,Ri) (i= 1..n) de verzameling original snapshots 

voorstelt die in een project geselecteerd worden voor adopt merge vanuit de merge-importdrawer, 

en er geldt: 

∀(ilt,Ri), ilt(Ri) ⊆ mil(Ri) waarbij i = (1..n) 

dan hoeven we geen 2 imports te plegen van dezelfde baseline. Voor merge hebben we dan 

enige vrijheid om ilt een beetje te variëren zonder een baseline opnieuw te importeren. 

Heerlijk dit orakelen met wiskunstige symbolen. 

Hoe merge verloopt is te vinden in 2.4.8 

Exact copy bij de start van het oplossen van een work-item. 

Als je ervan uitgaat, dat je een satellite kunt gebruiken voor het achtereenvolgens oplossen 

van een reeks work-items, dan kun je exact copy optimaliseren. 

Het betreft hier het synchroniseren van de satellite met de tip-tag van de team-drawer. In 

principe hebben we bij exact copy te maken met ild, els en rld. We gebruiken mogelijk 

geen els binnen een team. Voor rld kiezen we: alle courses in de satellite: elke course 

wordt ofwel beëindigd, ofwel de tip wordt uitgebreid, ofwel de tip wordt bevestigd door de 

geïmporteerde changeset. Uiteraard wordt ook de working-tree up-to-date gebracht. 

Merge copy bij het opnieuw synchroniseren. 

Voor de merge list is de vorige exact copy de verzameling originals. Het begint met commit 

van de gewijzigde files. De nu ontstane tips worden de neighbors in de merge list, tenminste 

als de version afwijkt van de base version. Dan exact copy met de tip-tag van de teamdrawer, 

dit wordt de verzameling bases in de merge list. Bij het uitvoeren van de merge 

worden de resultaten geplaatst in de working-tree. ild en rld blijven normaal hetzelfde 

gedurende het werk aan een work-item. In de merge list komen alleen die elements waarvan 

een neighbor is bepaald. De laatste merge copy plaatst alleen elements uit de envelopes in de 

merge list, en pleegt exact copy met de tip van de transfer-drawer. 

2. Exporteren naar andersoortige repositories. 

Archief-files (bijvoorbeeld zipfiles, of tarballs) van working-trees of info-trees worden 

geëxporteerd, of mogelijk slechts packages hieruit. Mogelijk wordt elk element voorzien van een 

property sheet file met attributes (metadata). Bijvoorbeeld: element helloworld.c wordt begeleid 

door helloworld.c.prop. Ik moet eens nagaan of hiervoor standaards zijn bedacht. Deze property 

sheets komen wat mij betreft in een schaduw folder structure, zodat ze op voorhand gescheiden zijn 

Pagina: 190 / 230




van de files, en folders. zijn, Middels een tool kunnen ze verenigd worden in de course van een 

element, of in de version. Een Climbexion tool moet deze property sheets genereren. 

3. Importeren van andersoortige repositories. 

Ook hier gebruiken we archief-files. De allereerste keer beginnen we met een lege satellite en 

working-tree, of een lege package hierin. Daarna prepareren we de satellite en zijn working-tree met 

de vorige versie. We vervangen de working-tree of het package in de working-tree door de archieffile. 

Een exact copy van working-tree naar de tip (en envelope) importeert de archief-file in de 

satellite. Meta data, – indien aanwezig –, worden ingevoerd met hulp van een Climbexion tool dat 

er de satellite mee wijzigt, en de envelope bijwerkt, en dat de version pool en kin pool bijwerkt. Als 

files verplaatst zijn, of een andere naam hebben gekregen dan betekent dit een breuk in de course 

van die files, tenzij de metadata voorziet in het behouden van de course, bijvoorbeeld door kins op 

te nemen als attribute. 

Climbexion baselines 

De software voor de diverse implementaties van Climbexion moeten compatible zijn. Een 

Climbexion subsystem voor pool onderhoud moet compatibel zijn met het subsystem voor drawers. 

Climbexion op servers moet compatibel zijn met Climbexion op Pc's. Climbexion systems binnen 

een master project moeten onderling compatibel zijn enzovoort. 

2.8.7 Virtualisatie 

Dit is niet iets dat vanaf het begin in Climbexion geïmplementeerd wordt. De "body" van 

Climbexion wordt gevormd door de opgeslagen versions. Al het andere: folders, courses, names, is 

"registratie en structurering"van een subset uit die body. Nu zijn er wel veel registraties van 

versions in drawers en hun satellites, in verschillende subprojects, en ze zijn overal "ongeveer" 

hetzelfde. Kan die registratie niet compacter, met minder redundancy. Bijvoorbeeld de importdrawer, 

moet die alle baselines bevatten van alle packages in een project, of hoeft die slechts 

verwijzingen te bevatten, naar de baselines in de export-drawers van andere teams? Voor de 

gebruikers kan het "paradigma"van de import-drawer intact blijven, De referentie is een 

"verborgen" registratie, die samen met een retrieval procedure de suggestie wekt van een 

"bevattende" opslag-methode. De methode kan gebruikt worden in import -, export -, team - 

drawers, satellites enzovoort. 

Bij de start van een drawer, dat wil zeggen: “ik denk bij de start van de meeste drawers”, wordt een 

snapshot gekopieerd uit een andere drawer. Dit geldt in ieder geval voor het merendeel van 

satellites. In plaats van kopiëren zou een reference opgenomen kunnen worden naar het snapshot in 

de andere drawer. Iets soortgelijks zou kunnen gebeuren in een satellite bij tussentijds opnieuw een 

base bepalen, of bij import-drawers bij het binnenhalen van een baseline. Hiermee zou je de DAG 

terugkrijgen. Als dit ooit geïmplementeerd wordt denk ik dat je weloverwogen moet besluiten om te 

kopiëren of te refereren. Net als bij clones geldt: wil je afhankelijk zijn van de beschikbaarheid van 

de andere drawer of van de performance van de verbinding of niet. Binnen de afdeling van NXP 

was er een uitstekend intranet met goede beschikbaarheid en goede performance. Maar de 

verbindingen met andere teams waren significant trager. Door de tijdsverschillen kon je soms 

niemand bereiken als remote repositories niet bereikbaar waren. Thuis en onderweg werken gold op 

ieder moment slechts voor enkelen, vanwege de afhankelijkheid van hardware, maar maar het gold 

Pagina: 191 / 230




altijd wel voor sommigen. En ook hier geldt als je kiest voor reference, dan wordt je afhankelijk van 

het internet. 

Mijn oorspronkelijke idee was dat iemand één of misschien twee satellites nodig zou hebben, later 

vond ik dat je een satellite moest hebben voor ieder probleem dat je oplost. Zo'n satellite kan 

beginnen met een reference naar een snapshot van een andere satellite, gevolgd door een exact copy 

vanuit een team-drawer, waarbij slechts verschillen hoeven te worden gekopieerd. Maar als je oude 

satellites verwijderd, dan moeten gerefereerde snapshots alsnog gekopieerd worden in de nieuwere 

satellites. Voor ongewijzigde elements moet het algoritme mogelijk een keten van references 

volgen. 

Local pools eisen dat je van alles dat je wilt zien een lokale kopie hebt. Je kunt iets maken met pool 

reeksen: eerst wordt lokaal gekeken of daar de kopie voorkomt, dan meer centraal, en misschien 

zelfs super centraal. Een nieuw exemplaar wordt om te beginnen zo lokaal mogelijk opgeslagen, 

maar verhuist, naarmate de kring van gebruikers toeneemt. Daardoor zou minder opslag van 

kopieën nodig zijn, en zouden sommige acties korter duren, maar andere weer langer. Verder geldt 

ook hier, wil je afhankelijk zijn van beschikbaarheid en performance van verbindingen, of toch een 

lokale cache gebruiken. Er is wel een trend om je altijd en overal afhankelijk te maken van digitale 

verbindingen. 

Info-trees, hoeven geen fysieke folders te zijn op disks in lokale pc's, of in file servers. Er kan een 

virtual file system gemaakt worden dat info-trees zichtbaar maakt als een folder, terwijl er slechts 

een script met query's (een voorschrift voor het samenstellen van de info-tree) echt bestaat. Zo'n 

info-tree kan niet gewijzigd worden: als je wilt wijzigen dan moet de info-tree gekopieerd worden 

in het lokale file system. Een dergelijk overzicht moet geleverd kunnen worden door Climbexion, al 

hoeft de virtuele info-tree niet per se zichtbaar te worden gemaakt met hulp van een virtual file 

system. 

Climbexion moet eerst maar eens werken voordat virtualisaties worden geïmplementeerd. Naast 

virtualisatie kunnen de paradigma mogelijk zelf herzien worden om te komen tot een systeem dat 

leaner en meaner is dan het prototype. Bijvoorbeeld: importeren in een import-drawer is overbodig, 

exporteren vanuit een export-drawer is overbodig. Voor al deze optimalisaties geldt: “Don't do it 

now”. 

2.8.8 Begrenzen? 

Package Feature (Requirement) List 

Een subproject maakt zo'n feature lijst voor ieder package dat in het subproject wordt bijgehouden. 

Dit is een goed uitgangspunt voor het verdere plan van aanpak, en het structureren van tests. 

Waarschijnlijk is ook dit een deel van SCM, immers dank zij zo'n list onderscheidt het package 

zich, ten opzichte van hetzelfde package in een ander subproject, dat een andere feature list heeft. 

Een belangrijke maar voorlopig vage eis is, dat de feature lists onderling vergelijkbaar zijn. Samen 

met een subproject tree, waarin te zien is hoe feature lists van elkaar zijn afgeleid, is dit best 

interessante informatie. De feature list, zelf kan als file worden opgeslagen binnen Climbexion, 

maar zijn editor, en de software voor de overzichten maken er geen deel van uit. Tijdens 

development is een dergelijk overzicht nuttige informatie voor stakeholders. De informatie is 

waarschijnlijk bruikbaar voor integrators bij de start van een nieuw (design-in) subproject, om te 

bepalen welk subproject het initiële package levert voor het nieuwe project. NXP heeft gedurende 

Pagina: 192 / 230




een bepaalde tijd zo'n systeem bijgehouden, in één van zijn teams. Toen de projects van dat team 

teneinde waren en het team is opgeheven, is het systeem waarschijnlijk niet overgenomen door 

andere teams. 

In de oorspronkelijke opzet werd één enkel MS Access bestand gebruikt over alle subprojects. Door 

deze opzet werd de informatie van een subproject niet bij het subproject in het revision control 

system geplaatst. In feite was er een een Access file per publieke component, dus niet per package. 

In de team organisatie was er een architect die verantwoordelijk was voor het hele package, en 

software engineers (de component owners) die verantwoordelijk waren voor de publieke 

componenten in een package. Feature lists werden bijgehouden per publieke component. Deze 

opdeling ontlaste de architect die als spil in het geheel fungeerde. 

Een Climbexion element is vaak een file. De basis entiteit van het feature list gebeuren is een lijst 

per subproject per component. Het ligt voor de hand om zo'n basis entiteit in een file te stoppen, en 

zo gebruik te maken van Climbexion voor opslag, distributie en identificatie. Voor de Feature List 

software betekent dit dat de subproject tree wordt samengesteld uit de files in de verschillende 

subprojects. 

Project documentatie 

Philips standaards zijn voortgekomen uit een IEEE standaard voor project documentatie. Reden om 

de documenten op te nemen in het revision control system: 

● uniformiteit en beschikbaarheid: er is één plaats waar deze informatie wordt bijgehouden en 

beschikbaar is. 

● Het revision control system wordt zo een zo volledig mogelijke gegevensbank waarin 

analyses kunnen plaatsvinden ten behoeve van project-evaluaties, en ter lering en vermaak. 

Normaliter is een project zo gestructureerd dat er een overall project is, dat bestuurd wordt namens 

de client van het project, en subprojects, één per team, of mogelijk, één voor een party. 

Ik zal nu niet bestuderen hoe de eventuele functionaliteit van Climbexion kan worden uitgebreid ten 

behoeve van het beheer van project documentatie. Climbexion is bedacht voor het opslaan van 

software, maar je kunt er misschien “ook” project documentatie in opslaan. Het “ook” gehalte is 

mogelijk niet al te best. 

Tools 

Als de tool beheerders behoren tot een team in het project, dan is er sprake van een gewoon 

package, ik heb het hier over tools waarvan het beheer op afstand staat van het project, met een 

onafhankelijke ontwikkeling. 

Opslag van tools is nuttig. Soms moet je terug in de ontwikkeling om bepaalde problemen te 

reproduceren, een andere keer wordt een package van een oud project het origineel in een nieuw 

project. In die gevallen moet je mogelijk terugvallen op het oude tool. Ook kun je in een team 

werken aan verschillende projects, die ieder een andere generatie van een tool gebruiken, of een 

tool van verschillende leveranciers. 

Toch zijn er grenzen. Een oud operating system, of een oude internet browser kun je terughalen uit 

een beëindigd project. Maar het lijkt onverstandig om het uit te voeren vanwege de veiligheidsrisico's. 

Ook als je werkelijk oud materiaal terugzet, dan kan het zijn dat het niet meer werkt of 

Pagina: 193 / 230




bouwt in enige beschikbare hardware/software omgeving. 

Een andere grens is er omdat er tools zijn die die niet in beheer zijn bij een project maar bij de 

“staande” organisatie. Bijvoorbeeld office en communicatie pakketten. Zelfs onderdelen van 

ontwikkelomgevingen zijn vaak niet project gebonden. Tools die bijgehouden worden buiten de 

drawer zijn potentieel een bron van problemen als een oud project wordt teruggezet. Bijvoorbeeld 

voor het repareren van een probleem bij een eindgebruiker van de TV is de toenmalige compiler 

met linker, en bibliotheek met standaard software nodig. 

Tool problemen bij het terugzetten van snapshots uit oude projects kunnen worden veroorzaakt door 

ongedocumenteerde variables en values in registries, environment tables of configuration files die 

nodig zijn voor een de build van een executable voor een specifiek hardware platform. Het is aan te 

bevelen om in zo'n geval de variable in te bedden in een specifiek script waarmee de build voor het 

platform wordt uitgevoerd. Het script is dan in ieder geval te vinden in een tools folder. En het 

script werkt environment variables en registries bij. 

Tools kunnen worden opgeslagen in een tarball of zipfile, als hun installatie weinig méér inhoud 

dan de folder met inhoud op een PC plaatsen. Tools kunnen opgeslagen worden als een installatie 

pakket als de installatie meer inhoudt en er ook registries of environment variables moeten worden 

bijgewerkt, of als delen van de software moeten worden geïnstalleerd in systeem folders. Ook een 

combinatie is mogelijk: een folder structuur in een archief file, en een script file om de omgeving 

aan te passen. 

Als tools worden opgeslagen als installatie pakket, dan moeten eventuele patches mogelijk 

afzonderlijk worden opgeslagen, zodat je eerst installeert en dan patches aanbrengt. Dit zal niet 

altijd gemakkelijk zijn, bijvoorbeeld als de patches worden aangebracht door internet update 

procedures, waarna ze niet meer zijn te lokaliseren. Als een tool wordt opgeslagen in het revision 

control system, dan moeten er wat dit betreft goede afspraken worden gemaakt met de leverancier. 

Soms werk je voor diverse projects. Als je werkt aan het ene project en je switcht naar het andere, 

dan wil je eigenlijk dat je slechts een andere folder in je filebrowser moet moet selecteren, of een 

andere drawer in je revision control tool en dan ben je over. Maar soms kunnen tools en hun 

omgevingseisen maken dat je een scripts moet uitvoeren als je switcht. Bijvoorbeeld omdat het niet 

mogelijk is om tegelijkertijd twee releases van één tool op één PC te gebruiken. 

In Climbexion komen in het begin geen extra voorzieningen voor tools. 

Build tools en uitbreidingen van IDE's. 

Voorlopig worden build tools niet geïntegreerd met Climbexion. Er zijn diverse build tools en IDE's 

die geïntegreerd zijn met een revision control system, met faciliteiten om een working-tree te 

synchroniseren, en wijzigingen met commit in te lijven. In het begin kunnen we bestaande tools 

gebruiken, en separate Climbexion software voor de diverse soorten synchronisatie, commit, 

envelope onderhoud en transfer. 

Testplek, kabinet, board, equipment administratie 

De redenen om deze administratie bij het revision control system op te nemen zijn dezelfde als die 

van project documentatie. 

Pagina: 194 / 230




De beschikbaarheid van de registratie betekent primair dat iemand kan vaststellen wat de meest 

geschikte testplek is voor de sessie die hij wil starten. 

Verder geldt ook nog dat, mocht het nodig zijn om een bepaalde configuratie opnieuw op te zetten, 

dat je dan kan zien in de administratie hoe dat moet, omdat een expert het ooit heeft voorgedaan. 

Een configuratie op een bepaalde tijd van een testplek beschrijft in feite wat er nodig was voor 

bepaalde test - of analyse - of debug - sessie. Uiteindelijk is dit een schat aan informatie, zeker als 

dit verband óók wordt vastgelegd. Bijvoorbeeld door een verwijzing naar de configuratie gegevens 

toe te voegen aan de log van een work-item. 

Om zo'n administratie goed up-to-date te laten houden zou je equipment (meestal signaal 

generatoren) mogelijk moeten uitrusten met RFID chips, zodat ieder op elk moment kan vaststellen 

waar het zich bevindt, en er niet naar hoeft te lopen zoeken. Daarnaast zou van equipment moeten 

worden geregistreerd in welke opstelling ze gebruikt wordt, misschien door automatisch vast te 

stellen in welk cluster stopcontacten het is ingeplugd. Deze en andere maatregelen zouden 

uiteindelijk moeten leiden tot een situatie waarin iemand zijn plaats niet hoeft te verlaten, om een 

testplek te kiezen, en de inrichting ervan te plannen. 

De software die in de testplek geladen is op een zeker moment behoort zeker tot de informatie die 

zou moeten worden geregistreerd. 

Tenslotte is er de registratie van audio en video streams, dvd's cd's en video tapes, patterns voor 

pattern generators die gebruikt worden in specifieke tests. Van dvd's cd en video tapes wil je graag 

weten waar ze uithangen, van patterns wil je weten door welke generators ze kunnen worden 

gegenereerd, van streams in welke folder ze staan, en van al deze dingen waarvoor ze geschikt zijn. 

Ook is het interessant om te weten wanneer in welke opstelling en waarvoor ze gebruikt zijn. 

Als je kans ziet om deze registratie goed voor elkaar te krijgen, betrouwbaar, actueel en zonder 

teveel overhead, dan rest nog het probleem van de kabels, snoertjes, plug adapters enzovoort. Bij 

het geschikt maken van een opstelling zou je hier niet naar moeten zoeken, of ze roven van een 

andere opstelling. 

Het hangt een beetje af van de laatste reorganisatie. Soms valt het middelen beheer onder de 

“staande”organisatie, dan weer wordt het beheer aangestuurd door een projectmanager voor de 

subprojects die onder zijn verantwoordelijkheid vallen. Project management zoals ik dat vroeger 

ooit geleerd heb (een cursus van Twynstra Gudde eind jaren 80), heeft te maken met fasering en met 

beheersing, en met voortgangsbeslissingen. Beheersaspecten, leerde ik, zijn: tijd, geld, kwaliteit, 

organisatie en informatie. Tegenwoordig zie je dat bijvoorbeeld risico beheersing een apart continu 

beheersaspect is (PMBoK in Wikipedia). In de TV software projects zou het middelen beheer ook 

wel in aanmerking kunnen komen om tot apart aspect te worden verheven. En in het overall project 

is het maken van prototypes en tv's voor testen, proef productie opstellingen reeds een bron van 

activiteiten. 

Dit is een separaat systeem. In Climbexion komen geen voorzieningen om aan te sluiten op dit 

systeem, trouwens verwijzingen naar specifieke hardware en testplek configuraties zouden eerder 

thuishoren in work-items, dan in envelopes. 

Installatie software 

In het verlengde van het build proces is er de installatie van software op een target system. 

Pagina: 195 / 230




Er zijn source systems waaruit files geselecteerd worden, een medium waarmee de geselecteerde 

files als package verzonden worden naar een target system. Working-trees of info-trees maken deel 

uit van de source systems. Op het target system moet worden gecontroleerd of de te installeren 

software er kan draaien, en zo ja dan moeten de files geheel of gedeeltelijk op het target systeem 

worden geplaatst. Soms moet de juiste variant van een onderdeel van het package worden 

geselecteerd. Misschien is de opslagstructuur afhankelijk van het target. Mogelijke referenties naar 

files of file inhoud moeten worden bijgehouden, en misschien moeten configuratie files en 

parameters worden aangepast. 

Bij CE werd reeds rekening gehouden met de trend om eindgebruikers of dealers gewijzigde 

software te sturen. De installatie software gebruikte dan ook security methoden zoals encryptie, en 

elektronische handtekening. 

Installatie software kan een package zijn binnen climbexion, Verder is er geen relatie met 

climbexion. 

Expertise database 

Het vinden van de juiste persoon voor een functie in een project, voor het toekennen van een 

werkopdracht, of voor hulp bij het uitvoeren van een werkopdracht, het vinden van zo'n persoon is 

niet altijd eenvoudig. Een database met de bekwaamheden van een persoon is dan ook gewenst. De 

database kan deels handmatig worden bijgehouden, deels automatisch door iemands bijdragen aan 

projects, packages, en work-items te monitoren. Ook de beschikbaarheid van iemand, zou 

vastgelegd moeten worden. Bijvoorbeeld: consultancy beperkt zich tot een team, een (master) 

project, een party, of is (tijdelijk) niet mogelijk. 

Recepten boek 

Hoe maak je een test script, hoe ziet een Koala pd file eruit, hoe zet je een debug sessie op tussen 

een PC en een TV, wat is Horcom, alles over aspect ratio: kijk in het recepten boek, gemaakt door 

iedereen voor iedereen. De lokale Wikipedia. 

Allereerst is een redactie nodig. Verder is een goed hypertekst programma onontbeerlijk. Aangezien 

een dergelijk systeem door iedereen wordt bijgehouden, ligt het voor de hand om een revision 

control system te gebruiken voor distributie, en onderhoud en status beheer. Het onderhoud van een 

dergelijk systeem is geen case study geweest bij het bedenken van Climbexion. Bijvoorbeeld: ik 

kan in dit hele epistel niets vinden over “overleg pagina's”. Het is daarom raadzaam om te kiezen 

uit voorhanden version control systems, aan de hand van een checklist, of om een hypertekst tool te 

kiezen, met een ingebouwd revision control system. 

Eén van de aandachtspunten is het selecteren van een context. Bijvoorbeeld: 

● Tijdschrijven wordt in elke afdeling gedaan, maar overal net iets anders 

● Debuggen in het ene project werkt met een andere debugger dan in het andere 

Als je dit systeem gebruikt is het misschien raadzaam om een profiel van de gebruiker en het 

gebruik op te geven alvorens te zoeken op een onderwerp als tijdschrijven of debuggen. Dank zij 

het profiel wordt je vraag naar “debugger” vertaald in: “de debugger van project X”. Je hoeft dan 

niet te vragen naar “debugger D”. Het recepten boek vertelt je dan om te beginnen, dat je “debugger 

D” moet hebben. 

Pagina: 196 / 230




De structuur van Climbexion is waarschijnlijk niet adequaat, er zijn diverse onderwerpen die niet 

gerelateerd zijn aan packages, teams en subprojects. 

In de periferie van dit systeem, bereikbaar via links bevinden zich de cursussen, presentaties, 

manuals en zo, die zouden mogelijk ook in een revision control system horen, dit pleit weer voor 

een onafhankelijk versie-beheer systeem, los van het hypertekst tool. 

Dit tool maakt geen deel uit van Climbexion. Een volledig en volwassen Climbexion zou misschien 

uiteindelijk ook de Wikipedia soort samenwerking moeten kunnen faciliteren. 

In NXP en in Philips-CE wordt een dergelijk systeem bijgehouden. 

Communicatie 

Mail, chat, twitter, blogs, web pages, chatrooms, audio/visual telefoneren en vergaderen: dit maakt 

geen deel uit van Climbexion. 

2.8.9 Gebruikersvriendelijke? id's 

Party, Team, Project 

NXP heeft een probleem: de ontwikkelingen in design teams en design-in teams in Eindhoven 

vinden plaats in één gebouw. Ook alle vertegenwoordigers van clients worden ontvangen in dit 

gebouw, en een aantal van hen moet soms toegang hebben tot de test plekken waar hun televisies 

staan opgesteld. Het is niet de bedoeling dat ze daar bij NXP op de hoogte worden gebracht van de 

activiteiten en ontwikkelingen van hun concurrenten. 

Tot mijn achtste jaar heb ik gewoond in de Lijsterbesstraat. Dit is een klein kronkelig straatje dat 

begint bij het kruispunt met de Essenstraat links, en de Glaslaan rechts, en de Kastanjelaan 

ertegenover. Het straatje komt uit in de Philips de Jonghlaan. We woonden tegenover de bakkerij. 

Wat geeft nu de naam Lijsterbesstraat precies aan informatie prijs? Wel als je “Lijsterbesstraat" 

tegen mij zei wist ik het precies: het was de straat waar ik woonde, niet al te ver van het spoor en 

de glaspoort van het Philips complex "Strijp I". Een Eindhovenaar weet dat het waarschijnlijk in 

het Philipsdorp ligt, net als de Iepenlaan en de Acasiastraat. Maar de meeste mensen zegt het niets. 

Je kunt vermoeden dat er lijsterbessen groeien, maar dat hoeft niet per se. Aan de naam kun je niet 

zien dat er een bakkerij gevestigd was, of dat ik er gewoond heb. Het feit dat het een straat is en 

geen laan zegt wel iets, misschien niet over de huidige status, maar wel de status van de weg toen 

de naam bedacht werd. Ondanks het feit dat het hier een "niet zinvolle naam" betreft (behalve dan 

het woord “straat”) is iedereen tevreden met de naam, en degenen die het aangaat weten wat 

ermee bedoeld wordt. 

Stel je noemt een project: “Sony Pnx315Chip USA”, dan hebben we het over een zinvolle naam. Je 

ziet wie de client is, welke chip gebruikt wordt en dat het project bedoelt is om een televisie in de 

Verenigde Staten van Noord Amerika in de markt te zetten. Misschien is er nog wel een zinvollere 

naam te bedenken die nog meer informatie bevat. 

Pagina: 197 / 230




Eindhoven, 5 december 

Beste Pleegbaas, 

Het doet mij genoegen u mede te delen dat het project 

LG-EU-MidRange-Internet-SuperSharp morgen klaar 

is 

Groeten, 

inhuurkracht Henk 

Typisch rondslingerende informatie 

In een omgeving waar discretie vereist 

is is het maar beter om een niet 

zinvolle naam te gebruiken, zodat 

rondslingerende informatie niet 

meteen alles prijsgeeft aan niet 

ingewijden. Een thema naam is dan 

een lichtgewicht bijdrage aan de 

discretie, en een laatste barrière als de 

geëigende maatregelen falen. Voor 

projects kies je bijvoorbeeld mieren 

als thema. De projects heten dan: 

“Formica rufa” (Rode bosmier, 

beeldmerk: een rode mier in het bos), 

“Lasius Flavus” (Gele weidemier), “Myrmica rubra” (Knoopmier). Voor teams kies je namen uit 

een ander thema (ook voor de teams van andere parties) en zelfs voor parties kun je je bedienen van 

thema namen. Geen naam geeft iets prijs behalve dat het een project, een team, of een party betreft. 

Dit kan natuurlijk alleen als je systemen en tools dergelijke namen toestaan. Climbexion moet nog 

gemaakt worden, dus ik ga ervoor zorgen dat het kan. 

Stel je kiest nummers voor teams, projects, en parties. Dan bestaat er toch een kans dat zingeving in 

de identifiers sluipt. Team 1831502 leest dan bijvoorbeeld als 18_315_02: 18: Toshiba, 315: chip 

PNX315, 02: Mips. 

Dergelijke names worden het best uitgegeven door een party. Er zijn dan diverse names in omloop 

voor hetzelfde project, hetzelfde team, en dezelfde party. Iemand kent alleen de betekenis van de 

names waarmee hij te maken heeft: men kent elkaars aanduidingen voor zover nodig. Climbexion 

moet in staat zijn om met dergelijke synoniemen te werken. In een team ziet je dan uitsluitend de 

eigen codering van projects, parties en teams. Ook kan het zijn, dat bepaalde gegevens in 

bijvoorbeeld envelopes zoals herkomst informatie niet beschikbaar worden gesteld buiten het eigen 

team. 

Als een thema verveelt kun je overstappen op een ander thema, ook de synoniemen die uit een 

dergelijke overgang voortkomen mogen geen probleem zijn voor Climbexion. 

Snapshots 

Bij snapshots heb je te maken met een drawer (of een package), en de inner-reach van die drawer 

(of dat package). Je kunt het snapshot nader specificeren met een timestamp of ook aanduiden met 

een baseline name of een tag name. Timestamps zijn nogal lang ten opzichte van tag names en 

baseline names. 

Ieder is vrij om names te bedenken voor Tags en Baselines: het zijn element names. Ze zijn net zo 

zinvol en kort als je wenst. Toevoegingen als drawer, package en project aan de name zijn 

overbodig want die hebben reeds de context bepaalt, waarin de snapshot aanduidingen gebruikt 

worden. Bijvoorbeeld als je vraagt: wat is de laatste baseline van package S in masterproject MP, 

dan verwacht je als antwoord: “baseline 3.2”, maar niet: “Package S, Masterproject MP Baseline 

3.2” 

Snapshot aanduidingen hoeven dus niet “globally unique” te zijn. 

Pagina: 198 / 230




Timestamp: 10 augustus 2008, 18:12:31 (27): erg veel 

Tag 10 augustus 2008, A.M: redelijk 

Baseline Week 32 2008 Kort, maar een vertaalslag naar 

gregoriaanse kalender is nodig voor 

veel mensen 

14 Nog korter, in principe een niet zinvolle 

naam, maar voor ingewijden 

betekenisvol. 

R3.2 3: laatst bereikte officiële mijlpaal, 2: 

volgnummer 

Een timestamp als snapshot is uitsluitend geldig voor de drawer, maar baselines en tags zijn 

overdraagbaar van de ene naar de andere drawer. Echter om bruikbaar te zijn buiten de original 

drawer moet de target drawer gesynchroniseerd zijn met een query waarin de baseline of tag 

gebruikt is. Voor de weergave van datum en tijd van een timestamp wordt de default van de 

betreffende desktop of laptop gebruikt. Misschien kun je kiezen voor een file system met een 

nauwkeuriger timestamp dan de huidige één seconde. 

Events en Course items 

Events kunnen worden aangeduid met een timestamp. De items die door een event toegevoegd 

worden aan de course van een element krijgen een additioneel nummer. Als tweede identifier voor 

zo'n item kan een sequence number gebruikt worden. Item sequence nummers kunnen dan gebruikt 

worden ter oriëntatie in de course van een element. Voor oriëntatie in een drawer kan men zich 

immers al bedienen van snapshot aanduidingen. De nummering vindt plaats per element (per kin 

per drawer) 

Kins 

Kins worden geïdentificeerd met behulp van een global unique identifier. Dit is niet erg 

gebruikersvriendelijk. Maar referentie vindt indirect plaats. De name van een element in een folder 

in een working-tree geeft bijvoorbeeld toegang tot de kin, maar je moet wel een Climbexion tool 

gebruiken om de working-tree te benaderen. Kin referenties blijven intact omdat projects uit elkaar 

ontstaan, door packages of hele drawers te kopiëren vanaf design projects, of vanaf design-in 

projects van dezelfde client. 

Kins van packages worden opgenomen in de eigen pools, en hebben in ieder geval een referentie in 

de administrator database. 

Elements 

Een element wordt geïdentificeerd door een drawer en een kin. Maar toegang krijg je door het 

gebruik van een name in een folder in een working-tree, of info-tree of snapshot (virtual info-tree). 

In feite door middel van een path-name. 

Pagina: 199 / 230




Versions 

Voorlopig houdt ik het er maar op het volgende : ze worden geïdentificeerd met een eigen identifier. 

Voor de eigen identifier wordt tegenwoordig een cryptografische hash van hun inhoud genomen. Ik 

meen dat Monotone hiermee is begonnen. Er is een traditie om deze files op te slaan in de vorm van 

delta's ten opzichte van hun voorganger in een verzamel tekst file, tenminste ik meen dat ik dat ooit 

gezien heb bij PVCS. Voor een eerste aanzet van Climbexion is deze compressie techniek nog niet 

nodig, en misschien wel nooit. In één package kunnen in een snapshot identieke versions 

voorkomen in verschillende files, die niet tot dezelfde kin behoren. Deze worden dus maar één keer 

opgenomen, immers hun hash is hetzelfde. Door de inhoud uit te breiden met de kin id en ook 

daarover de hash te bepalen kan dit vermeden worden, maar de vraag is of dat nodig is. Een rare 

consequentie kan zijn, dat je een version vastlegt in je satellite, en prompt krijgt hij een andere 

“timestamp last changed”, omdat hij gelijk is aan een bestaande version. De vraag is of je dat moet 

vermijden door de inhoud uit te breiden met de timestamp: er kan een merge door worden uitgelokt, 

die feitelijk overbodig is. Bij versions hoort metadata in de vorm van attributes. Deze attributes 

zoals timestamp en user-id zouden niet moeten bijdragen aan de hash, zodat er geen overbodige 

kopieën worden opgenomen in de pool. 

versions worden als volgt gekozen: 

● via de course van een file. 

● Door het gebruik van een name in een folder in een snapshot, of working-tree. 

● Door referentie vanuit een envelope. 

Drawers 

Hun duiding: een type aanduiding zoals “team-drawer”, “import-drawer”, “export-drawer”, “expose 

drawer full”, “expose drawer restricted”. Dit alles is niet eenduidig. Een project name hoort erbij, en 

soms een package name. Die project name betreft dan het subproject waar deze name betrekking op 

heeft. Satellites worden aangeduid met hun center en een additionele (user) name, of door een 

center een additionele name en een reference naar een work-item. Drawers zijn waarschijnlijk een 

file of een folder of beide. Als zodanig worden ze ook geïdentificeerd door een URL. Drawer type 

aanduiding en subproject samen specificeren de constellation. 

Envelopes 

Envelopes krijgen een sequence number. Samen met een constellation is dit een unieke aanduiding. 

External envelopes 

Binnen het master project krijgen ze een sequence number. 

2.8.10 Losse eindjes 

Opslag en afvinken van merge conflict lijstjes. 

Opslag van scripts (bijvoorbeeld voor Import limitations). 

Opslag van templates. 

Opslag van definities en data betreffende filetypes, file subtypes, file extensies, file gerelateerde 

Pagina: 200 / 230




tools, backward en forward compatibility. 

Vastleggen van entiteiten en entiteitsvertalingen. 

Structureren van Other-focused file pools. 

Pagina: 201 / 230



2.9 Slotopmerkingen 


Het gebruik van locations: Het is de bedoeling dat dit de security bevorderd, maar ook dat het 

extensible en flexible is. En dat het de mogelijkheid creëert om te werken met abonnementen op 

bestaande database servers en file servers, of om als organisatie deze servers aan te schaffen. Voor 

de file servers waarin versions zijn opgeslagen geldt: een directory structuur is niet per se nodig, 

maar support van de security die Climbexion vereist moet geïmplementeerd zijn. Ook is support 

van file forks gewenst om metadata te implementeren. Voor drawers, en pools van kins, en van 

envelopes geldt waarschijnlijk dat een database server volstaat. 

Compressie technieken van de file server kunnen misschien wenselijk zijn, bijvoorbeeld als de 

hoeveelheid software en data harder groeit dan de hoeveelheid opslagruimte, als die dan duur en/of 

schaars wordt. Climbexion kent de base waaruit een nieuwe version is ontstaan, In het begin wordt 

deze informatie niet vastgelegd in het filesysteem. in de toekomst zou een filesysteem met “delta” 

compressie in principe mogelijk zijn, als daarin voor elke successor één of alle bases worden 

vastgelegd. 

Toestaan dat wijzigingen van name en folder membership mogelijk zijn binnen een kin, en zelfs 

binnen een course, is zo'n beetje een uitdaging. In dergelijke gevallen een nieuwe kin beginnen is 

natuurlijk te simpel. Voor een tool dat folder structures synchroniseert zoals robocopy of voor 

commander software en directory compare software is dit mogelijk een probleem. Voor de 

ontwikkeling van Climbexion betekent dit dat je niet zomaar een van deze programma's kan 

pakken, en dan de inputs en outputs ervan vervang door access op drawer snapshots en tips. Voor de 

gebruiker betekent het dat er meer vrijheid is om namen of indelingen te wijzigen, terwijl de 

methode om te synchroniseren intact blijft. In Climbexion ligt de grens bij het package, als je een 

element verhuist buiten het package, dan moet er een nieuwe kin komen. 

De log die bijgehouden wordt door de course van een envelope is in de eerste plaats bedoeld om bij 

te houden wat er is nodig geweest om een oplossing volledig in de repository te krijgen. Ook kun je 

daarin nagaan hoe het verloop van een changeset is geweest door de overdrachten heen. Deze 

informatie kan van pas komen voor het verbeteren van procedures, maar ook voor het vinden van 

een fout-oorzaak. 

De courses van eigen elements in de eigen drawers zijn uitgebreider dan de courses in die waarin de 

elements zijn gedistribueerd en overgedragen. Deels komt dit de zakelijkheid ten goede, deels de 

besproken discretie want dit verbergt mogelijk enig inefficiënt handelen, dat iemand niet aan de 

grote klok wil hangen. Evaluaties ten behoeve van product-verbeteringen zijn uitvoerbaar in 

drawers met geëxposeerde elements. Voor evaluaties ten behoeve van werkwijze (of gedrag) 

verbeteringen gebruik je meer lokale drawers en satellites. Ze staan ten dienste van degenen die hun 

eigen werkwijze willen of moeten verbeteren. Dit principe wil ik er eigenlijk wel inhouden, bij 

herzieningen van de paradigma. Bij proces of gedrag moet je bijvoorbeeld denken aan tekenen van 

besluiteloosheid: de envelope wordt wel/niet/wel ingevoerd; of tekenen van halve oplossingen: een 

envelope is in drie fasen gewijzigd, voordat de oplossing klaar was; of transfer problemen: 

regelmatig komt het voor dat de daily build mislukt, of de acceptatie test. 

Dezelfde gegevens die dienen voor werkwijze verbeteringen kunnen van belang zijn om de oorzaak 

van een fout te achterhalen. Als blijkt dat iets is fout gegaan door een wijziging van Lagus, dan kan 

Lagus met hulp van zijn satellite mogelijk de oorzaak van de fout achterhalen. Zelfs als de oorzaak 

Pagina: 202 / 230




niet direct is af te leiden, dan kan de registratie in de satellite het geheugen opfrissen en zo 

bijdragen aan inzicht in de oorzaak. Als de oorzaak bekend is kan dat aanleiding zijn tot een 

verbetering van de kennis van Lagus, of tot verbetering van de manier waarop hij werkt, of de 

manier waarop in het algemeen wordt gewerkt, en tot een inschatting van mogelijk andere fouten. 

Er is nogal nadruk gelegd op discretie en geheimen en gentleman agreements en zo, maar ja dat 

hoort een beetje bij de aard van de elektronica industrie: de organisaties zijn rivalen, vaak moeten ze 

samenwerken en soms treffen ze elkaar als ze aan het shoppen zijn, bijvoorbeeld bij dezelfde chip 

fabrikant. Soms krijg je de indruk dat ze werken met patent genererende machines –, een paar 

honderd per dag of zo –, voor patenten waarvoor ze geen licentie verstrekken, om zo de 

concurrentie te dwarsbomen. Effecten kunnen zijn dat een nieuwkomer met nieuwe ideeën geweerd 

wordt en dat idee over idee niet gerealiseerd wordt. Dit zijn twee bijdragen aan innovaties, en dus 

aan omzet. Voor de branch als geheel en daarom ook voor individuele competitors is openheid en 

licentie verstrekking waarschijnlijk beter, en product en fabricage geheimen zouden niet lang 

moeten duren. 

De synchronisaties die ik heb geschetst: initieel synchroniseren van een satellite, tussentijds “bij 

synchroniseren” van een satellite als een ontwikkeling wat lang duurt, synchronisaties vlak voor een 

transfer van een satellite naar een center-drawer, synchroniseren van een package uit een ander 

project. Deze synchronisaties vragen om een goede set commando's en hun parameters om precies 

weer te geven wat de bedoeling is. Deze en andere commando's behoren tot de “human computer 

interface” van het systeem, en moeten ontworpen worden in de fase “methodische probleem 

beschrijving”. 

Wat kan een prototype van Climbexion opleveren? 

● Methoden als Problem frames en Orm/Niam worden gebruikt voor een niet triviaal systeem 

op een manier die gepubliceerd kan worden, en wie weet misschien moeten ze er een beetje 

voor aangepast worden . 

● Het structureren van de informatie voorziening met in acht neming van eisen van discretie 

volgens het model van Dorothy Denning: dit is fun voor de liefhebbers, als het tenminste 

niet te triviaal blijkt te zijn 

● Enige ervaring met temporele problemen kan worden opgedaan. 

De software die mogelijk voortkomt uit mijn analyses is in principe niet (universeel) bruikbaar: ze 

is immers niet gebaseerd op een gedegen markt onderzoek. Het is dedicated software, voor een 

bedrijf dat lijkt op NXP's tv competence centers, en klanten die lijken op één van hun klanten ten 

tijde van pakweg 2001-2008, en gebaseerd op enkele schetsen van werkwijzen. Mogelijk is het 

verleidelijk om zo te structureren dat delen ervan hergebruikt kunnen worden voor domeinen 

waarvoor andere eisen gelden dan ik beschreven heb. Maar persoonlijk ben ik een beetje allergisch 

voor het woord “ook”. Het klinkt naar slechtzittende tweedehands kleding: Het pak is gemaakt voor 

Jan, maar Piet kan het “ook” aan. 

Binnen NXP heb ik gewerkt in een drietal teams. Waarschijnlijk is Climbexion geschikt binnen die 

teams. Voor de teams waarmee we samenwerkten en voor de andere teams in NXP gelden andere 

interne werkwijzen, en dus zijn er mogelijk andere varianten van een revision control system nodig. 

Voor de gegevens-uitwisseling zou het wel prettig zijn als opslag en transport gestandaardiseerd 

zijn, maar werkwijzen moeten kunnen variëren: er is mogelijk een zeer lange weg te gaan om te 

komen tot een commercieel product. 

Pagina: 203 / 230




Vlak voor ik met pensioen ging (2008) gaf CE de Amerikaanse markt op, dat wil zeggen, dat ze de 

tv's lieten ontwikkelen door een Taiwanese firma. Het lukte NXP niet om zijn chip te verkopen aan 

die firma, dus dat was gevoelig verlies van marktaandeel. In 2011 kwam het bericht dat Philips CE 

helemaal ophield met de eigen fabricage van televisies. Het is best wel speculatief wat ik er hier 

over zeg. De aanpak met gemeenschappelijk ontwikkelen was goed en gaf een voorsprong toen er 

van scratch af aan begonnen moest worden, toen alles nog moest worden ontwikkeld en 

geïntegreerd. Later, toen er meer onderlinge zakelijkheid en plug en play vereist werd, zagen ze 

misschien geen kans die overgang te maken. Om in de gekozen cooperation projects toch een plug 

en play packages op te leveren is niet triviaal. Immers zonder harde verificatie is er geen garantie 

dat software aan een bepaald criterium voldoet: je moet er voortdurend op controleren, en de 

gevonden problemen oplossen, zoals bij gewone bugs. Bij samenwerken is het verdelen van werk 

vaak een kwestie van onderhandelen. UHAPI alleen lijkt onvoldoende en CE heeft ook te maken 

met allerlei applicaties. Climbexion is, omdat het voornamelijk is gebaseerd product families en op 

samenwerking (zonder veel plug en play), misschien slechts optimaal bruikbaar in een zeer 

specifieke situatie. De les: in de pionier fase moet je reeds veel meer ontwikkelen voor plug en play 

en “independent deployment” in de volgende fasen. 

De werkwijze toen, kan veranderen. Bijvoorbeeld als “independent deployment” bereikt wordt, is 

minder samenwerking nodig. Als de programmeer taal C wordt opgevolgd door een moderne taal, 

dan zal dit mogelijk de teams kleiner maken, de betrouwbaarheid van de software vergroten, en zo 

de werkwijze veranderen. Iets soortgelijks geldt als men overgaat op vernieuwde best practices. Er 

is binnen NXP een trend gesignaleerd om steeds meer computers en processors te gebruiken in het 

moderne elektronische speelgoed, en niet slechts één steeds krachtiger. De werkwijze en mogelijk 

de samenwerking verandert als er met zeer veel computers gewerkt gaat worden. Voor digitale 

televisies geldt ook nog dat die in het begin veel innovaties vereisten, maar naarmate de tijd 

voortschrijdt wordt het “meer van hetzelfde”, alleen goedkoper. Al deze veranderingen kunnen de 

behoefte aan bepaalde karakteristieken van een version control system veranderen. 

Kortom zonder goed empirisch onderzoek wordt het nooit wat, maar blijft het een hobby. Trouwens, 

als je met een tool wilt komen voor een bepaalde commerciële branch, zoals consumenten 

elektronica, dan zullen er standaards moeten worden afgesproken. Er zal moeten worden 

geparticipeerd door de ondernemingen in een commissie of zo, die de samenwerking en de tools die 

daarbij horen specificeert, en mogelijk de software tools uitgeeft. Ik denk wel dat dit open 

standaards en vrije software tools kunnen zijn, waardoor ze gemakkelijk en goedkoop beschikbaar 

zijn voor onderwijs, voor instappers, en buiten de branche. 

Een “bedreiging” van software revision systemen lijkt de ontwikkeling van de bestandssystemen 

ZFS en Btrfs / CRFS te zijn. Het lijkt erop dat dergelijke systemen met snapshots en branches 

rechtstreeks de opslag methode van revision control systems kunnen zijn. Voor Climbexion zou dan 

het drawer/pool opslag systeem uit de tijd raken. Ook het working-tree / view-tree idee zoals wij dat 

kennen gaat dan op de schop. 

Het prototype is zeker niet praktisch bruikbaar. Er zijn omissies zoals splitsen of samenvoegen van 

packages, opvolging van een package door een andere, integratie met een IDE en zo. Verder heeft 

een prototype een belabberde performance denk ik. 

Pagina: 204 / 230




Het werk van een kamergeleerde 

Zoals uit het plaatje blijkt is de pleister vooral 

bruikbaar voor lijf en leden van echte mensen 

Er is het gezegde: “het eerste huis bouw je voor 

je vijand, het tweede voor je vriend, en het 

derde voor jezelf”. Zoiets zal ook wel gelden 

voor een software systeem. Het “eerste huis” 

zouden sommige bestaande revision control 

systemen kunnen zijn. De eerste officiële versie 

van Climbexion, als het ooit zover komt, is voor 

een vriend. Je moet natuurlijk wel jezelf aan 

banden leggen, tenminste als je één van de 

wetten van Brooks wilt overwinnen: “Het huis 

voor jezelf –, of misschien reeds dat voor je 

vriend –, komt nooit af, want je wilt het te goed 

doen en te mooi maken”. Maar ja aan de andere 

kant, dit is ook voor studie, en wat mij betreft 

voor de lol, en om de tijd te doden. 

Door andere bezigheden werk ik slechts 3 

dagen per week enkele uren aan dit stuk. Voor 

een ruwe schets van het revision control system 

en het gebruik ervan heb ik tot nu toe drie jaar doorlooptijd besteed. Nu begint een meer formele 

probleem beschrijving, met methoden waarmee ik nog niet eerder heb gewerkt. Als ik dat tenminste 

niet nog een jaar uitstel, ik zie nogal op tegen het formeel beschrijven. Ik ben waarschijnlijk te oud 

en te blasé om mij nog een methode eigen te maken zodanig dat ik ermee kan lezen en schrijven. 

Het lezen van een boek, en daarna in je eentje achter de PC ermee werken is niet meer de juiste 

manier voor mij om me de stuf eigen te maken. Uiteindelijk lukt mij slechts een informele 

beschrijving. Desalniettemin hoop dat u aan dit epistel enig plezier hebt beleefd. 

Wat ik wilde maken was een speeltuin waarin wat gespeeld kan worden met methodisch 

ontwikkelen van niet triviale systemen. Tot nu toe zat ik in mijn eentje achter mijn PC. In je eentje, 

dat kan uiteindelijk niet de bedoeling zijn van een speeltuin. 

Pagina: 205 / 230


3 Methodische probleem beschrijving 



3.1 Inleiding 

3.1.1 ORM 

Dit is een “stappen methoden” 

De stappen in ORM worden gezamenlijk “Conceptual schema design procedure (CSDP)” genoemd: 

0. Splits het “universe of discourse” in handzame delen 

1. van voorbeelden naar feit expressies en voer een kwaliteit controle uit 

a) Verwoordt bekende voorbeelden (tot feiten) 

b) Verfijn ze tot formele elementaire feiten en verifieer deze 

2. Teken de feit typen en en maak er voorbeelden bij van feiten 

3. Kijk of entity typen moeten worden gecombineerd en toon afleidingen 

4. Bepaal hoe feiten geïdentificeerd kunnen worden(uniqueness constraints), en controleer de 

de feit expressies op het aantal rollen (arity). 

5. Bepaal verplichte rollen, en controleer op logische afleidingen 

6. Bepaal de wetmatigheden (constraints) die gelden voor waarden en (entiteit) verzamelingen, 

en hoe verzamelingen zich onderling verhouden (deelverzameling, gelijkheid, exclusie) 

7. Bepaal de overige wetmatigheden en voer laatste controles uit. 

8. Integreer de subschema's in één globaal conceptueel schema 

De ORM aanpak met stappen zijn aantrekkelijk in een project-fase, planbaar, en voortgang 

zichtbaar en zo. De methode lijkt strikt gebaseerd op bestaande praktijken, of concrete voorbeelden. 

De schema's zijn een tussenproduct tussen de bestaande praktijk en de nieuwe database. 

In een bestaande praktijk zijn er bestaande reports, graphical user interfaces, command sets en 

dergelijke. Dus eigenlijk is er al een “extern schema” van de database, en ook een implementatie 

schema. In een nieuw bedacht systeem en zelfs in een overnieuw bedacht systeem moet dit nog zijn 

vorm krijgen, en is er mogelijk een kip ei probleem met het conceptuele schema. 

De information modeling techniek beschrijft “elementary fact types”. Deze zijn waarschijnlijk al in 

de vereiste normaal vorm voor temporele databases (6nf volgens Wikipedia), gewoon omdat ze 

elementair zijn. ;-) 

3.1.2 Problem frames 

Als je de inhoudsopgave bekijkt van het boek: “systeem ontwikkeling volgens SDM” van H.B. 

Eilers, ((ik heb de 8e druk) 1990 ISBN 90 6233 177 7 Academic Service) dan zie je onder meer het 

volgende: 

1.2 Verzamel gegevens over de bestaande situatie 

1.3 Analyseer de bestaande situatie 

1.4 Bepaal doeleinden en eisen nieuwe systeem 

Wat opvalt is het volgende: analyseren doe je een situatie, eisen stel je aan een systeem. Mijn 

aanpak is tot nu toe zo'n beetje: 

1.2 Inventariseer en analyseer de oude situatie 

Pagina: 206 / 230



3.1 Inleiding 

1.3 Ontwerp nieuwe situatie 

1.4 Bepaal doeleinden en eisen nieuwe systeem 

Waarbij de situatie zowel "het (version control) systeem" als de organisatie en werkwijzen betreft. 

Aan punt 1.4 zijn we nu bijna toe. 

Omdat het beschrijven van een nieuw version control systeem door mij, een ex software engineer, 

tot hobby gemaakt is, worden er mogelijk eisen gesteld die je normaliter in de design fase van de 

software tegenkomt. Maar ja, als "owner" mag je eisen wat je wilt, zelfs implementatie details. Dit 

komt natuurlijk niet alleen door mijn achtergrond. De "situatie" zowel oud als nieuw bestaat nu 

eenmaal uit beide de organisatie en het systeem, en nieuwe eisen kunnen aan elk onderdeel van de 

situatie gesteld worden en vandaar "gepropageerd" naar veranderingen in de hele situatie, en eisen 

aan alle onderdelen. Het eerste context diagram en de beschrijving ervan is een poging om dit in 

kaart te brengen. Maar daarna moet toch echt begonnen worden met punt 1.4: alles toespitsen op de 

nieuwe machine en de nieuwe database, volgens de methode beschreven door Michael Jackson. 

Het opvallendste probleem dat niet behandeld wordt door M.J. is de eis van distributie, van locaties 

waar een machine draait met databases, die mogelijk communiceert met identieke machines die 

conceptueel identieke databases gebruiken (waarvan de inhoud verschilt). Of van identieke 

machines die dezelfde databases benaderen. Misschien dat daar geïmproviseerd moet worden. 

3.1.3 JSP 

Hoe komen de voorbeelden tot stand? In plaats van het ontwikkelen van een gebruikers interface, en 

van reports zal ik voorlopig uitgaan van batchfiles die beschrijfbaar zijn met Jackson's JSP 

schema's, of met reguliere expressies. Ik verwacht dat het mogelijk is, dat ze slechts een one read 

ahead procedure vereisen om ze te ontleden. Later kunnen de reports, de command language, en de 

GUI dan daadwerkelijk worden ontworpen, met lettertypen, kleuren, lay-out, porties, snapshots en 

dergelijke. Een JSP schema is dan de “structuur” van een sequentiële file met data. De dubbele 

specificatie, in de vorm van gepresenteerde voorbeelden (views) enerzijds en conceptual schema 

anderzijds, die blijft dan gehandhaafd bij het toepassen van ORM. Waarom JSP schema's en 

batchfiles in plaats van XML schema's en XML files? Waarschijnlijk jeugd sentiment: wij 

gebruikten JSP in de jaren 70 als opvolger en uitbreiding van de balance-line methode uit de jaren 

60. Meer informatie over JSP schema's: “Principles of Program design” door M.A. Jackson 

(Academic Press 1975, ISBN: 0123790506 ). De verwachting is dat het merendeel van de 

voorbeelden op deze manier te beschrijven is. Een enkele maal kan het voorkomen dat “one read 

ahead” niet toereikend is, of dat een structuur niet met reguliere expressies is te beschrijven. Dan 

wordt er enigszins geïmproviseerd om de structuur te tonen. 

In Jackson schema's bestaat een strikte definitie van nodes: Een node is een leaf, een sequence, een 

iteration, of een aantal alternatives. Optional bestaat niet, in plaats daarvan is er het alternative: een 

node A is of een a of niets. Deze strikte definitie is nodig als alle input en output files gezamenlijk 

gebruikt worden om een procedure te construeren: men zoekt naar “matching”nodes. Stel dat de 

constructie “een A is een A1 gevolgd door een A2, A2 is een iteratie van a2” vervangen wordt door 

het minder strikte “een A is een A1 gevolgd door een iteratie van a2”, en A2 is een matching node, 

dan kan de methode niet uitgevoerd worden. Handig voor de communicatie over de structuren en 

het matchen is de naamgeving: iedere node heeft een label. 

In feite gebruiken we de JSP schema's als prototype voor een deel van de gebruikers interface. 

Pagina: 207 / 230



3.1 Inleiding 

Zodra de gebruikersinterface zelf gespecificeerd is, is het prototype overbodig. De strikte definitie 

van nodes maakt hopelijk dat de uiteindelijke interface kan worden vergeleken (kan matchen) met 

het prototype. 

JSP schema's beschrijven de syntaxis van een sequentiële file. Zo'n file wordt dus feitelijk gezien 

als een string met een “alfabet” Het alfabet waarmee de string wordt gemaakt, die voldoet aan het 

schema, bestaat uit “record-typen” of “tuple types”, ieder record-type heeft zijn eigen formaat: een 

opsomming van variables (fields, attributes, roles). Het Jackson schema zoals wij dat gebruikten 

ging dus niet door tot de laatste byte. De volgorde van de variables doen niet ter zake in een Jackson 

programma, want een record wordt altijd in zijn geheel gelezen in de meest gebruikte implementatie 

taal van JSP: Cobol. Deze volgorde is meestal wel belangrijk in voorgaande of volgende sorteerprogramma's: 

alle records worden gesorteerd op dezelfde posities. Nu we JSP schema's niet 

gebruiken voor een “batch” architectuur maar als prototype voor een gebruikersinterface, is het niet 

nodig om gemeenschappelijke sorteer velden te specificeren in de record-types. 

De “leafs” van een Jackson schema representeren de record typen. Dit is ongeveer waar. Leafs 

kunnen hetzelfde record formaat hebben, en toch semantisch onderscheidbaar zijn. Bijvoorbeeld, 

iemand wordt lid van een club en na een jaar zegt hij zijn lidmaatschap op. Er is dan een “join” 

event en een “leave” event. Deze events kunnen beide geregistreerd worden met het record formaat 

“event record”. Het attribute “event type” kan de waarden “join event” of “leave event” hebben. Er 

is dan geen 1-1 relatie tussen een record formaat en een leaf. 

Het is te verwachten dat de uiteindelijke presentaties zijn te “matchen” met de voorlopige JSP files. 

Jackson beschrijft een aantal conflicten die direct matchen onmogelijk kunnen maken. De 

belangrijkste is het volgorde conflict (order clash), die optreedt als een presentatie in een andere 

volgorde moet worden gemaakt of verwerkt dan de oorspronkelijke file. Als tweede is daar het 

interpretatie conflict (boundary clash): de volgorde stemt overeen, maar de structuur die je ziet in de 

ene string gegevens is niet vergelijkbaar met die van de andere string. Ten derde is er het meng 

conflict (interleaving clash), waarbij tenminste één der gegevens stromen gesplitst moet worden in 

meerdere die elk vrij van conflicten zijn ten opzichte van de andere stromen. Ik verwacht dat deze 

problemen doorgaans zijn te vermijden. Mochten ze toch optreden, dan zullen we de door Jackson 

aanbevolen oplossingsmethode gebruiken, en zo alsnog aantonen dat de voorlopige en de 

uiteindelijke presentaties verwant en gelijkwaardig zijn. 

3.1.4 HCI 

Onlangs heb ik bij “de Slegte” het boek gekocht: Human Computer Interaction: Issues and 

Challenges. Qiyang Chen (Idea Group Publishing, ISBN 1-8782889-91-8) 

De eerste 3 hoofdstukken heb ik inmiddels enigszins gelezen. 

In hoodstuk1: Interface Design: An Embedded Process for Human Computer Interactivity; Antonio 

Drommi, vond ik onder meer een “Audience checklist”, en een sectie “Diversity and cultural 

elements”: verscheidenheid van gebruikers moet leiden tot standaarden en opties van de gebruikers 

interface. Een consequentie is dat de verzameling opties moet worden gespecificeerd, gemaakt en 

gebruikt. Voor het een eerste aanzet kan worden uitgegaan van een homogene eentalige gebruikersclub 

denk ik. 

In hoodstuk2: User Interface Development Throughout the System Development Life-cycle; Scott 

Pagina: 208 / 230



3.1 Inleiding 

Ambler. Hier vond ik een methode voor het ontwikkelen van modellen van “major en minor user 

interface elements” met behulp van flipovers en sticky notes, en een user interface flow diagram. 

De documentatie-wijze kan ik adopteren in mijn requirement specifications, maar snapshots ervan 

moeten dan toch elektronisch worden vastgelegd, zodat de ontwikkelingsgang is te volgen. 

Misschien is het mogelijk om hetzelfde te doen met een case tool (en een beamer, als men met 

meerdere mensen tegelijk aan het ontwerpen is). 

In hoofdstuk 3: From HCI to Interaction Design. Jonas Löwgren. Hier vond ik de bewering dan 

HCI meer is dan een software laag. Dat is natuurlijk waar. Begrippen als team, kin course, 

envelope, patch dringen in het systeem door tot in de database, maar zijn ook in gebruik bij de 

mensen. Ook werd hierin uitgelegd dat HCI niet rechtlijnig is te ontwikkelen (van requirement tot 

implementation), maar een leer-proces doormaakt waarbij het uiteindelijke resultaat niet meer is 

geënt op de oorspronkelijke requirements (dit idee bestond ook reeds in de voorgaande 

hoofdstukken). Voor een eerste aanzet zou je zo rechtlijnig mogelijk te werk te moeten gaan, daarna 

mag er naar hartenlust geïtereerd, geleerd, en geëxperimenteerd worden, maar liefst wel van 

“werkend geheel” naar “werkend geheel”. 

Veel van de begrippen die gehanteerd worden in Climbexion zijn reeds gemeengoed in het 

toepassingsgebied. Anderen zijn nieuw of vernieuwd door Climbexion. In de loop der ontwikkeling 

kan blijken dat dingen niet ongewijzigd zijn te handhaven. Met name het wilde idee om lokale 

namen te gebruiken voor projects, parties en teams zou best kunnen sneven omdat het onpraktisch 

is. (In dit stadium, – waarin de SCM systemen “eilanden” van automatisering zijn, die in gebruik 

zijn binnen teams en parties –, is het trouwens gebruikelijk). Maar ja, nu we toch een leerproces 

moeten ondergaan kunnen we het wel een kans geven. Mocht in de loop der ontwikkeling blijken 

dat er geen praktische invulling kan worden gevonden voor het idee dan schrappen we het. 

Database onderhoud, onderhoud van optie verzamelingen: het basis frame van Jackson is het 

workpieces frame. Een GUI lijkt een voortraject , waarin de “commands” en “notifications” 

geselecteerd en gevormd worden die worden losgelaten op de “workpieces”. Ook zaken als 

scrollen, copy/paste, view-modes en dergelijke blijven mogelijk buiten beeld in het basis frame 

door de behoefte om “essentials” te registreren in de requirements. De methode van Scott Ambler 

specificeert dit voortraject. Uitgangspunt voor de user interface is het resultaat van ORM en de 

workpieces frames. 

Niet uit een boek, maar van mijzelf. Wat is de overeenkomst tussen TV software, database software 

en repository software? 

● Ze hebben een gebruikers interface. Ja logisch dat weten we ook wel. 

● Ze zijn een gebruikers interface. TV software is een interface naar TV hardware, database 

software is een interface naar een database, repository software is een interface naar een 

repository. Ja logisch, dat weten we ook. 

Ik wilde je er toch maar even aan herinneren. 

Pagina: 209 / 230



3.2 Context diagram 


● Parties: 

Teams, Projects, Product families en Products worden erin benoemd. 

Security en confidentiality worden geëist door parties. De vereiste security omvat export 

limitations, access rights, Backup en recovery, inbraak beveiliging, en dergelijke. 

Samenwerken wordt afgesproken door parties. 

Een team binnen NXP bedient vaak een deel van de parties, vaak één, soms twee, van de 

klanten waarmee samen een nieuwe generatie chip / tv wordt ontworpen, of veel van de 

parties die daarna de chip willen afnemen. 

● HW / SW architectuur: 

Packages en Components in een (general) framework worden benoemd en bijgehouden 

door de architecten. De eis dat Climbexion packages moet kennen komt hiervandaan. 

Ook de eisen voor het registreren van folder entity types komt voornamelijk voort uit de 

architectuur, zoals bijvoorbeeld “component folder”, “interface folder”, “publieke 

componenten folder”, “unit-test folder”. 

De packages en components bepalen ook mede de teams en roles voor persons. Packages 

zijn atomen voor de teams, en components zijn soms atomen voor component owners. 

Atomen: je beheert nooit 2,77 package, maar altijd een geheel aantal. 

● Product families: 

Ze worden bepaald door de parties. 

Pagina: 210 / 230 

Domains and Requirements




Product family members zijn gerelateerd aan projects. Een member uit de TV family 

bevat één member uit de chip family en bepaalt vaak een master project. Zo'n member 

kent vaak nog wel varianten: er is bijvoorbeeld een eco chip en een power chip, zodat 

een Europese eco TV, een Zuid-Amerikaanse power TV samen in hetzelfde 

masterproject ontworpen kunnen worden. 

“Adopt” wijzigingen zijn een vereiste als je werkt met product families, tenminste als je 

software ontwikkeld per familielid. 

● Projects: 

Een subproject bedient één master projects en bestuurt daartoe één team. Ze zijn een 

entity voor administrations en misschien voor Climbexion. Door de subproject structuur 

van een master project zijn er baseline en patch overdrachten van de software. 

Project management wil alle personen optimaal en tegelijkertijd aan het werk hebben, en 

onderling wachten beperken. Daaruit volgen eisen voor base/labored paren, eisen van 

mergeability van source files, het eisen van een center/satellite structuur en de eis om 

other-focused files te onderkennen. 

Kwaliteit waarborgen bij overdrachten worden in het kader van project management 

gespecificeerd, en ingevoerd. Hieruit volgen eisen voor tests, reviews, gebruik van tools 

voor statische analyses en gebruik van build tools voordat wordt overgedragen. 

Ook wil ze product en onderdelen identificeren, en er de status en voortgang van kunnen 

vaststellen. 

Verschillen tussen subprojects voor wat betreft de software engineering cultuur, kunnen 

leiden tot verschillen in case tools. Hieruit kan de volgende eis afgeleid worden: Het 

moet mogelijk zijn om build resultaten op te slaan, want subproject A zal soms met 

andere talen en compilers of andere design tools werken, dan subproject B, waardoor ze 

elkaars build resultaten niet kunnen (of willen) genereren. 

● Teams: 

Ze bedienen meerdere subprojects, en bij NXP meestal slechts één lid, soms enkele 

leden van de eigen product family. 

Ze beheren enkele packages voor de betreffende leden van de product family. 

Teams die meewerken aan een gezamenlijke ontwikkeling beheren vaak enkele van de 

packages van NXP. Meestal bedienen ze subprojects voor een klein deel van de cliënten. 

Teams, die werken voor de parties die daarna de chip afnemen, beheren vaak alle 

packages van NXP. 

Teams en de rolverdeling van personen binnen teams zijn belangrijke entiteiten voor 

administrations, voor de specificatie van access rechten. 

● Person: 

Persons horen normaal in één team, maar kunnen “uitgeleend” zijn aan andere teams, 

zodat ze soms hun tijd verdelen tussen meerdere teams. 

Ze zijn geregistreerd in de administrations, en hebben access rechten in de repositories. 

Bij elke wijziging in Climbexion wordt de persoon die de wijziging teweegbrengt 

geregistreerd. 

Software engineers willen self-focused files opslaan, en test engineers willen daarnaast 

nog allerlei other-focused file opslaan, zoals test-results en allerlei status reports. 

● Temporal database design: 

Deze wetenschap levert de begrippen valid time en transaction time, die gebruikt worden 

in Climbexion en in Administrations. 

Pagina: 211 / 230




Snapshot registraties en snapshot queries komen hieruit voort. 

● Case tools: 

Merge tool: dit moet gebruikt kunnen worden in Climbexion repositories. 

Build tool: dit tool moet op “different time” zijn gebaseerd, want gegenereerde code 

moet worden opgeslagen in Climbexion om export limitations te realiseren, om optimaal 

werken te realiseren, en om verschillen tussen teams voor wat betreft case tools te 

overbruggen 

Build tool: het build tool stelt een eis aan het file system, misschien aan alle tools die 

files wijzigen, en aan Climbexion, als het werkt met “different version identifier” 

(checksum, hash) als alternatief voor “different timestamp”. 

Een IDE heeft vaak faciliteiten voor het onderhouden van de tip van de satellite, en de 

working-tree. En om een info-tree te onderhouden en af te leiden van een snapshot van 

een drawer. 

Tools leveren de filetypes en file entity types, de viewers, editors, en mogelijk een deel 

van de templates. Ook behoren tot de tools de template wizards, die aan de hand van 

ingevulde menu's de template genereren. 

Files zoals vervaardigd door een tool dat in gebruik is voor het ene project kan 

incompatibel zijn met het tool van een ander project. Dus is een eis aan Climbexion om 

compatibiliteit checks uit te voeren bij “adopt” operaties. 

Tools worden gebruikt voor “quality assurance” na wijziging of merge om zo een 

bepaalde status van bruikbaarheid te garanderen voor de versions in de repository. 

Teams en personen moeten kunnen werken met meerdere generaties van een tool 

tegelijk, op dezelfde computer. 

● Het File system: 

Dit systeem levert de begrippen “file”, “folder”, “soft-link” en eisen die aan de 

identificatie van files, folders en soft-links worden gesteld. 

working-trees en info-trees zijn gerealiseerd in het file system. 

● Geography: 

Hier komt het begrip “location” vandaan . Het geheel aan drawers en pools, is verdeeld 

over (netwerk) locations. Een drawer of een pool staan slechts op één location. 

Teams zijn gebonden aan een verdieping in een gebouw: een (ruimtelijke) location, 

Parties bevinden zich op soms op meerdere locations. Ruimtelijke locations bezitten 

vaak een intranet, waarin zich de netwerk locations bevinden. 

Netwerk locations zijn computers, met permanent geheugen. Een gedeelte van dit 

geheugen is in gebruik voor Climbexion, omdat daar een deel van de repository staat. 

Personen kunnen een laptop bezitten. Terwijl de persoon zich verplaatst, verplaatst de 

netwerk location van zijn laptop zich. Toch wordt zijn laptop beschouwd als de vaste 

location waarop een deel van de repository staat. 

Het bestaan van Climbexion locations stelt eisen aan de manier waarop kins en versions 

gecodeerd worden. In geval ze met zijn allen in één location ontstaan, kun je met 

sequence nummers werken, maar bij het gebruik van meerdere locations, waarvan een 

aantal mogelijk niet tijdig bereikbaar, moet je een andere manier van coderen gebruiken. 

(een (cryptografische) checksum of hash of een timestamp of beide voor een version, 

een guid voor kins). Hoewel de identifiers gegenereerd worden, zijn ze geenszins 

verborgen voor gebruikers: ze maken deel uit van hun wereld. 

Het bestaan van Climbexion locations stelt eisen aan de manier waarop wijzigingen 

Pagina: 212 / 230




moeten worden doorgevoerd. Voor wijzigingen met een course of development zijn de 

overdrachten primair georganiseerd van en naar drawers, en extra, vanwege de locations, 

de wijzigingen van pools. Voor wijzigingen die een course of corrections vormen zijn 

extra maatregelen nodig om ze door te voeren. Met name als ze deel uitmaken van een 

pool. (upload naar een centrale pool, download naar locations). 

● Security methods: 

Globally Unique Identifiers, Secure Hashes: de algoritmen hiervoor zijn standaard. Ze 

worden onder meer gebruikt voor file versions en kins. Hashes worden ook gebruikt bij 

elektronische handtekeningen. 

Origin warrant met private en public keys over secure hashes. Ze worden gebruikt in 

envelopes, bij baselined packages, bij aanmeldingen en dergelijke 

Access permissions op drawers pools, servers en dergelijke. 

Classification methods. Ze worden gebruikt als geheimen niet verstuurd mogen worden, 

of niet toegankelijk mogen zijn voor iemand, terwijl het betreffende deel van de 

repository wel toegankelijk is. 

● Source files en Test-scripts: 

Source files zijn de klassiekers: version control systemen zijn oorspronkelijk bedacht om 

die erin op te bergen. 

Test-scripts zijn programma's dus daarvoor geldt in principe hetzelfde. 

● Status en progressie documenten en build resultaten: 

Een belangrijk voorbeeld zijn files met test resultaten. 

Ze slaan op een snapshot, maar niemand wil erop wachten. Voordat ze er zijn, of voordat 

ze klaar zijn, is het snapshot reeds historie. Vandaar de eis aan other-focused versions 

om zowel een transaction time als een valid time aanduiding te hanteren. 

Waarom moet het een repository zwerm zijn? 

● Het moet een repository zijn want: 

Daardoor is de data beschikbaar voor allen. 

Door de centrale opslag is er overzichtelijkheid. De status kan worden vastgesteld. 

● Het moet een zwerm zijn want er zijn samenwerkende gestructureerde organisaties. 

Een organisatorische eenheid moet in staat zijn om zijn deel van de repository toe te 

spitsen op zijn behoefte, bijvoorbeeld met behulp van import limitations. Maar het is wel 

belangrijk om ook het geheel te zien. Voor dat geheel zijn bijvoorbeeld de importdrawers. 

Een organisatorische eenheid –, een party, een afdeling, een persoon –, moet zijn eigen 

bestaan en eigenheid beschermen, dus iets aan zelfhandhaving doen. 

▪ Daarom is er de behoefte aan privacy, in de vorm van team/transfer drawers voor 

teams, en satellites voor personen 

▪ Daarom is er behoefte aan een façade, in de vorm van baselines en export-drawers 

voor teams, export limitations voor parties, envelopes voor personen. 

Met een zwerm is veel en gemakkelijk parallel werken mogelijk. 

Waarom moet historie worden opgeslagen, en moeten repositories bewaard worden en toegankelijk 

blijven? 

● Het parallel werken op de manier van climbexion betekent dat ik vandaag andermans werk 

gebruik van gisteren terwijl anderen vandaag mijn werk van gisteren gebruiken. Er is dus 

een tijd-venster waarin zowel de versies van gisteren als die van vandaag beschikbaar 

Pagina: 213 / 230




moeten zijn. Als je kijkt naar baselines dan moet het venster minstens enkele weken groot 

zijn. De opslag in de vorm van historische reeksen (courses), snapshots en dergelijke is het 

paradigma waarmee we deze versies ordenen. 

● We hebben historie nodig om regressie te lokaliseren, om het project te evalueren, om 

werkwijzen te verbeteren, om verantwoording af te leggen. Het tijd-venster wordt nu de 

project duur. 

● Bij product families, waarbij een nieuw lid ontstaat door veel uit een oud lid opnieuw te 

gebruiken, moet je soms ver terug in de tijd om te ontdekken waarom een constructie is 

zoals hij is. Het archiveren moet daarom minstens voor enkele jaren zijn. 

● Soms moeten er ruzies worden beslecht die gaan over project bijdragen, auteurschap, 

patenten, kopieerrechten en dergelijke Een repository is dan mogelijk zeer gewenst. 

● Een jubilaris of pensionaris wil je graag nog eens confronteren met het werk dat hij gedaan 

heeft. Archieven moeten nu al gauw 40 jaar bewaard worden. 

● Je hoopt toch altijd dat iemand er nog eens een boek over schrijft, of er een scriptie over 

maakt. 

Pagina: 214 / 230



3.3 Repository Database 


3.3.1 Envelopes 

1. Het probleem is voor het eerst opgelost in project “Veluwe” maar moet nu ook opgelost 

worden in project “Ardennen”. 

2. De successor lijst is leeg, want er zijn geen voorgangers die een halve oplossing bleken, of 

opvolgers, omdat de oplossing in deze envelope incompleet was. Successors verschillen van 

comrades, omdat ze nooit collectief worden overgedragen, en per se op hetzelfde work-item 

slaan. 

3. Toen Lepus het probleem toekende aan Lagus, heeft hij de envelope gecreëerd. Vervolgens 

heeft Lagus de wijzigingen aangebracht in zijn satellite, en daarna overgedragen naar de 

Transfer-drawer. 

4. Dienstdoend integrator Rida heeft een acceptatie test uitgevoerd, en de wijzigingen 

overgedragen aan het team-drawer. 

Pagina: 215 / 230 

Structuur van een envelope




5. Er zijn 2 files gewijzigd. Van iedere file zijn er 2 versies gewijzigd, maar slechts één 

gewijzigde versie is overgedragen (heeft passages ondergaan): Ieder item moet tenminste 

één wijziging bevatten waarvan de base in de envelope overeenkomt met de tip in de 

ontvangende drawer. 

6. De wijzigingen zijn overgenomen uit een neighbor. 

7. comrades zijn hier niet ingevuld. Bedoeld zijn envelopes op dezelfde activity en in hetzelfde 

team, in een ander package, of op hetzelfde. Bijvoorbeeld: als een nieuwe baseline van een 

package van een ander team wordt overgenomen, dan moeten er soms patches en 

Pagina: 216 / 230 

Voorbeeld van een envelope




wijzigingen in een aantal packages worden geïmplementeerd, samen met die nieuwe 

baseline. De comrade lijst moet (automatisch) hetzelfde zijn in alle comrades. De lijst is 

geordend en moet in die volgorde worden overgedragen naar transfer en team-drawer, in één 

atomic action. Een weigering van een 

item in één van de comrades betekent een 

transfer weigering van alle comrades. De 

envelope nummering van comrades: Ze 

hebben allemaal hetzelfde hoofdnummer, 

maar een verschillend volgnummer. Ze 

kunnen verwijzen naar verschillende 

work-items, maar die moeten tot dezelfde 

activity behoren. 

8. Er zijn speciale waarden voor de 

attributes base en labored om aan te 

geven dat een course beëindigd wordt of 

(weer) begint. 

9. Een element dat in een eerdere passage 

meedeed, maar nu niet meer, moet toch 

worden gebaseerd op de tip in de 

ontvangende drawer. maar “labored” 

krijgt dezelfde waarde als “base”. 

10. Als de lijst met items van een envelope 

significant zou wijzigen bij een nieuwe 

overgang van satellite naar transferdrawer, 

dan kan men beter de envelope 

op rejected zetten en een successor 

benoemen. Bijvoorbeeld als original en neighbor niet toepasbaar zijn op alle base/labored 

alternatives van een item. 

Pagina: 217 / 230 

Envelope state diagram 

State transitions worden gerealiseerd in 

passages. De gekleurde pijlen geven passages 

weer waarbij daadwerkelijk items worden 

overgedragen van de ene drawer naar de 

andere.




3.4 Het administrator subprobleem (zeer voorlopig) 

Van alle domains is de organisatie de enige die niet nu ontworpen is. De beschrijving hiervan is 

“real world”, al het andere moet ontworpen worden, en is “problem to solve”. De primaire 

requirements zijn is in feite: 

● de eis dat de SCM machine de juiste informatie krijgt betreffende de access rights van 

degene die ingelogd is, of die inlogt, 

● de eis dat de SCM machine de volgende informatie kan bemachtigen: welke server wordt 

waarvoor gebruikt, en hoe moet de server worden benaderd. 

Afgeleid hiervan is de requirement dat de organisatie, en met name de administrator in staat moet 

zijn om deze informatie te verstrekken en actueel te houden, om fouten in deze informatie op te 

sporen en te verbeteren, en soms om verantwoording af te leggen voor datgene dat geregistreerd is. 

De consequenties hiervan voor de database en de machine en de administrator moeten in dit 

document duidelijk worden. 

De te ontwerpen administrator machine wordt in veelvoud geïmplementeerd, Iedere machine heeft 

zijn eigen administrator, en zijn eigen database. Er zijn shared phenomena (i) tussen deze machines, 

niet alleen omdat ze gemeenschappelijke begrippen hanteren, maar ook omdat zij elkaar raadplegen. 

● Het bijhouden van de database door de de administrator: een workpieces concern. 

● Het vergaren van informatie uit de database: een transformation concern 

● De luxe van een grafische gebruikersinterface: Ambler's major and minor elements and flow 

diagrams for user interfaces 

● De SCM machine die op verzoek informatie moet ontvangen: information display concern? 

● de Administrator machines die informatie moeten ontvangen: information display concern? 

● Het starten en stoppen en wijzigen van deze information display concerns: commanded 

behavior concern? 

Waarom display concerns voor de informatie die machines nodig hebben? Kan een machine niet 

Pagina: 218 / 230 

Problem diagram Administrator




elke keer een request sturen als er informatie nodig is? Met het display concern blijft de 

mogelijkheid open dat een gewijzigde administrator database een proces interrumpeert, dat anders 

zou voortgaan op niet actuele data. Als complicatie betekent dit mijns inziens ook: zorg dragen voor 

acties bij een verbroken contact. 

a) Administrator! 

• Maintain ids names properties and relationships of parties, teams, projects, persons, 

packages, locations 

• Asks to show contents of database 

• Allows content retrieval to other administrators/administration machines 

• Initiate Receive/Request content from other administrators/administration machines 

• Login/Logout 

Administration Machine! 

• Graphical user interface 

• Errors & Confirmations 

b) Organization! 

• Supply information to maintain the database: We want to be registered like this 

Administrator! 

• Report database status: You are registered like this 

c) Organization! 

• Its structure must be maintained correctly in order to behave as trusted software 

factory 

d) Database queries: SQL 

e) [c] Organization/Package/Location Model. For access rights in the parties part of the 

version control system: register the allocation of people to teams and projects, register the 

allocation of projects and packages to locations(servers). For locations in other parties 

register the administrator database (of another party) that maintains this information, for its 

part of the version control system. 

[f] [g] Interaction to maintain the database, and obtain info from it. 

[h] obtaining access rights and location and file info, in order to allow and provide access to 

the version control system. 

f) Administrator! Being a mediator between organization and machine 

g) Repository machine! 

• Subscribe on access permissions, 

• Subscribe on server access data (location info) 

Administrator machine! 

Pagina: 219 / 230




• Send access permissions. 

• Send Server access data 

h) Delayed, until SCM machine is described. 

i) Administrator machine! 

• Subscribe on project data, 

• Subscribe on subproject data. 

• Subscribe on package data 

• Subscribe on user data 

Administrator machine! 

• Supply on project data, 

• Supply on subproject data. 

• Supply on package data 

• Supply on user data 

De eerste stap van ORM begint met de voorbeelden. In principe zijn dit “views”. Views horen thuis 

in de interface van de administrator machine met de administrator, en in de interface tussen de 

administrator machine en de SCM machine en in de interface tussen administrator en organisatie en 

in de interface tussen administrator machines. De combinatie van de twee methoden: Problem 

frames en Database design hebben een consequentie: 

Eerst wordt dat deel van de de interfaces beschreven waarin de primaire informatie behoefte 

wordt gedefinieerd: de requests van de SCM machines aan de administrator machine, dan 

wordt daarvan afgeleid de informatie die de administrator nodig heeft om de gegevens voor 

deze requests te onderhouden: de secondaire informatie behoefte. Een deel van deze 

phenomena heeft de administrator nodig tijdens zijn interacties met de organisatie. Als je 

kijkt naar de herkomst van de gegevens, die de administrator nodig heeft, dan blijkt dat een 

aantal gegevens in de eigen administrator database onderhouden worden, De administrateur 

krijgt deze gegevens eerst van de organisatie, en daarna uit zijn eigen database. Maar andere 

gegevens worden gevonden in SCM locations (bijvoorbeeld package pools), of in 

administrator databases van andere parties, (bijvoorbeeld masterproject data en data van een 

subproject van een andere party). Deze distributie van gegevens bepaalt een aantal interface 

phenomena tussen de machines: de tertiaire informatie behoefte. Dan wordt het database 

ontwerp gemaakt waarin de de integratie van deze views wordt beschreven. Dit is de 

domain description van de database. Tenslotte wordt de interactie die nodig is om de inhoud 

van de database te wijzigen afgeleid van het database ontwerp. Dit zijn weer phenomena in 

de interface tussen machine en administrator. De indeling in secties in dit document wordt 

afgeleid van het problem frame, van de domains en interfaces die daar staan. Deze secties 

zijn ontstaan in een stappen volgorde: wil je die volgen dan moet je hoppen van de ene 

sectie naar de andere. Ik zal merktekens als primair, secondair, en dergelijke toevoegen 

zodat de analyse/ontwerp volgorde van het probleem enigszins is te volgen. De strikte eis 

van NIAM en opvolgers om te beginnen met voorbeelden wordt in tweede instantie 

uitgevoerd voor alle interfaces beschrijvingen. Eerst wordt de (data-) structuur van de 

interfaces uit de doeken gedaan als een soort mindset. 

Pagina: 220 / 230




3.4.1 Interface Administrator machine / SCM machine 

We nemen aan dat een beheerder van een SCM Machine deze voorziet van adres en 

toegangsgegevens van de Administrator Machine van de organisatie (party) waartoe zij/hij behoort. 

Primair 

1. SM! Monitor welke rol is weggelegd voor uit in 

AM! uit in heeft 

2. SM! Stop monitoring uit in 

User id Party subproject Set of roles 

vanOorschotH Schoener Geldrop {Ontwikkelaar, 

Build manager} 

JansenGMPP Schoener Heeze {Integrator, 

Architect} 

DijkstraJ Schoener Geldrop {Ontwikkelaar} 

deVriesKL Schoener Mierlo {Beperkte Gast} 

Bebr2701 Tjalk Geldrop {Volledige Gast} 

Kareltje Fregat Leende {} 1 

1)Een empty set roles wordt geretourneerd als een gebruiker geen rol heeft, of als een User id, Party 

of subproject niet bestaat, of als een User id niet geregistreerd is bij de Party. 

3. SM! Monitor het server address van 

AM! 

4. SM! Stop monitoring 

Resource type Naam URL Subscription Return 

subproject Veldhoven s1 OK 

package-DB Frontend s2 OK 

package-FS Anadec s3 OK 

subproject Feldhoven s1 error 

De namen die gehanteerd worden zijn local names, zoals die in de party van de administrator 

database worden gehanteerd. De SCM machines die de gegevens willen hebben zijn eigen servers, 

of eigen client machines. 

Voorlopig houd ik het hierbij. Het aanmelden, het verzorgen van een secure interface, het zorgen 

voor een eenmalige aanmelding van een gebruiker, uniform contact maken met elke server – indien 

mogelijk – Voorlopig ga ik ervan uit dat een URL volstaat, maar er zijn mogelijk ook nog 

protocollaire eisen. 

Pagina: 221 / 230




3.4.2 Interface Administrator / Machine 

Secondair 

Iedere party heeft zijn eigen administrator(s) en zijn eigen machine en zijn eigen administrator 

database. Ik gebruik Jackson schema's voor het structuren van de gegevens, 

In principe zijn er 4 soorten variables in de records: 

• Variables voor het herkennen van het soort record. Meestal is dit het “Record type”. Ze zijn 

als volgt beschreven: naam = waarde 

• Variables die afkomstig zijn uit de eigen administrator database. Deze zijn als volgt 

beschreven: naam 

• Variables met gegevens die uit andere resources dan de eigen administrator database komen. 

Deze zijn als volgt beschreven: naam 

• identifiers van objecten uit een mogelijk andere resource: naam 

Roles (de rollen die teamleden spelen): dit veld is van het type “set” (verzameling) dit wordt 

weergegeven als volgt: {Roles} 

Pagina: 222 / 230




Eigen teams 

team-id: [recordtype=teamid, id, timestamp created, timestamp ended] 

codename: [recordtype=codename, code name, timestamp] 

Person-id: [recordtype=person, name, userid, mail address, phone number, 

public key] 

Personroles: [recordtype=personrole, timestamp, {actual role}, {potential 

role}] 

package-id: [recordtype=packageid, kin, name, db URL, fs URL] 

package-join: [recordtype=packagejoin,eventtype (join team/leave team) 

timestamp] 

subprojectdata: [recordtype=subproject, local code name, local code name of 

master project, sp location URL, timestamp start, timestamp end] 

subproject-join: [recordtype=subprojectjoin,eventtype (join team/leave team) 

timestamp] 

Guest-id: [recordtype=guest, name, userid, {role}, mail address, phone 

number] 

Guestrole: [recordtype=guestrole, {actual role}, timestamp] 

Een potential role definieert wat iemand kan, een actual role definieert wat iemand mag. Personen 

en gasten worden alleen vermeld als ze een actual role vervullen of hebben vervuld. Als hun actual 

roles een empty set geworden zijn, dan is hun role voorlopig uitgespeeld. Role is van het type "Set". 

Mogelijk splits ik dit op in een file voor "team name", één voor "people", één voor "packages", en 

één voor "subprojects" 

Pagina: 223 / 230




Personen 

Person-id: [recordtype= personid, userid, name, public key, mail address, 

telephone] 

Potential role: [recordtype= potentialrole, {role}, timestamp] 

Team-id: [recordtype= teamid, teamname] 

Actual role: [recordtype=actualrole, {role}, timestamp] 

Pagina: 224 / 230




Eigen packages 

main pools: [Recordtype = locations, kin-pool URL, version-pool URL] 

Guid & status: [Recordtype = kin, Timestamp born, kin, Timestamp status 

update, Status (born,registered)] 

Name: [Recordtype = name, Name] 

Event: [Recordtype = event, Type (Allowed, Obsolete), Timestamp] 

Team-id: [Recordtype=teamid, name] 

Team-join: [Recordtype=teamjoin , Type (join/leave), Timestamp ] 

Pagina: 225 / 230




Eigen Master projects 

Data: [recordtype=masterproject, Global code name, Local code name] 

Person id: [recordtype = personid, Name, userid, mail address, telephone 

number] 

Roles: [recordtype=roles, timestamp, {roles}] 

Subproject data: [recordtype= subproject, Local code name, Local code name 

party, admin URL] 

package: [recordtype= package, name, kin, Kin pool 

Pagina: 226 / 230 

URL, 

Version 

pool 

URL]




Eigen subprojects 

Data: [recordtype=data, local code name, Sp URL, timestamp started, 

timestamp ended, local code name Master Project] 

Team: [recordtype=team, local code name, timestamp] /* course */ 

package: [recordtype=package, kin] 

subprojects zijn overdraagbaar van het ene team naar het andere (niet aanbevolen). 

Pagina: 227 / 230




Alle master projects (eigen en participaties) 

Master project data: [Recordtype = master project, Local code name, Code 

Name, Local party code name, Admin database URL] 

Subproject data: [Recordtype= subproject, Local code name, Code name, Local 

party code name, Admin database URL /* admin database of party*/] 

package: [Recordtype = package, Prefered name, kin, export_drawer URL, Kin 

pool URL, Version pool URL] 

Member data [Recordtype=team member, User-id, Name {Roles /* in own 

subproject */}, mail address] 

Roles: [Recordtype = local roles, {Roles /* guest roles in local subprojects 

*/} ] 

De (non local) Code Names zijn de namen die in het master project gehanteerd worden. De Local 

Code Names zijn de namen die binnen de eigen party gebruikt worden. 

Pagina: 228 / 230




Party Lijst 

Party data: [Local code name, Own code name, Admin database URL] 

Master Project: [Local code Name, Own code name] 

Subproject: [Local code Name, code name in master project, local name of 

Master project] 

Van de eigen party is de lijst compleet, maar van andere parties ziet men alleen de projects waarbij 

men betrokken is. 

Pagina: 229 / 230


4 Licentie 

4 Licentie 

4 Licentie 

De tekst is beschikbaar onder de licentie Creative Commons 

Pagina: 230 / 230 

Naamsvermelding/Gelijk delen.

Climbexion revision control voor softwarewerkplaatsen Henk ...

Create successful ePaper yourself

Delete template?

Save as template?