Opa vertelt: programmeren (4)

Meer Opa vertelt
Meer Opa vertelt

Zoals beloofd in een voorgaande aflevering van deze serie, nu iets meer over het lange tijd bij de PTS-cursus gebruikte rode-draad voorbeeld van de Homevox.

De homevox is (beter was) lange tijd een populaire huistelefooncentrale waarop maximaal vier telefoons aangesloten konden worden (via een draadje, draadloos was in die tijd nog niet zo in de mode) en waarbij zowel intern als extern gebeld kon worden. Via authentieke documenten van de PTT (en wellicht een beetje eigen creativiteit) werd een pakket aan eisen opgesteld en was het aan de cursisten om het hele traject van analyse, ontwerp en implementatie van de software voor zo’n systeem te doorlopen.
Zoals gebruikelijk in dit soort zaken spraken de eisen elkaar soms tegen, waren soms onduidelijk of vaag en was zeker niet alles afgedekt.
De ontwikkeling is in een aantal iteraties uitgewerkt en vooralsnog eerst op een hoog abstractieniveau, dus zonder daadwerkelijk de hardware aan te spreken. Er is gebruik gemaakt van UML en van de iteratieve methode zoals Larman die omschrijft.
De iteraties betroffen: interne gesprekken, toevoegen externe gesprekken (zowel uitgaand als inkomend) (waarbij als belangrijke beslissing in de ontwerpfase het gebruik van het zg. rollenpatroon), verbeteren van eerste opzet van externe gesprekken (i.h.b. het voorkomen van dublicatie van code door een extra initieelCall-object aan te maken).
Om de gecreëerde software meer realistisch te testen is tot slot een poging gedaan de hardware te simuleren. Voor de verschillende hardwarecomponenten zijn klasses bedacht en de al gemaakte stuursoftware is vervolgens aangepast zodat deze de hardware-objecten rechtstreeks aan konden spreken. Voor simuleren van die hardware lagen twee mogelijkheden voor de hand: een draad wordt met een signaal geassocieerd, een draad kan meer signalen gelijktijdig bevatten en de signalen worden veroorzaakt door events die het begin of het eind van zo’n signaal aangeven; dit is het zg. signaal-model. Een alternatief zou kunnen zijn uit te gaan van het connectie-model, waarbij de verbindingsfunctie van het netwerk zelf voorop staat. Het connectie-model is verder uitgewerkt. Alle hardwarecomponenten zijn dan specificaties van de component-klasse, waarbij een schakelaar voorgesteld moet worden door een twin-object (d.w.z. twee objecten stellen één schakelaar voor) omdat een schakelaar twee aansluitpunten heeft.
Een volledige uitwerking incl. hardwaresimulatie is gerealiseerd.

Het hele homevox-project gaf een goed beeld van de mogelijkheden en de aanpak van het zg. Unified Process. In bijgaande pdf vind je nog eens de volledige uitwerking, zoals die tot 2001 is gebruikt en uitgedeeld.
Ergens heb ik van deze case ook nog de volledige uitwerking in Java. Helaas is die uitwerking nog niet erg grafisch zodat het als demo minder geslaagd is.
Het homevox-project geeft overigens wel aan dat het goed mogelijk is binnen redelijke tijd een min of meer compleet echt werkend systeem te genereren uitgaande van min of meer realistische eisen en wensen (incl. hun onvolledigheid, tegenstrijdigheid en vaagheid) zonder te vervallen in een al te simpel toy-example.