boek over hoe een programma opbouwen

[Havoc]

Heeft er iemand een titel van een boek over hoe je een programma schrijft? Niet over de programmeertaal zelf en hoe loops etc in elkaar zitten. Maar hoe je het programma zelf aanpakt, opdeelt etc zodat het handelbaar blijft, afhandeling van fouten, checken van input, ... die dingen die maken dat het ipv 1 blok waar je later niets meer van snapt en moet herbeginnen

Heb wel leren programmeren op school (lang geleden) en de technische zaken zitten er nog wel in. Ik snap de datatypes, lussen, testen etc. Maar heb eigenlijk nooit meer gedaan dan zo van die typische oefeningen als "geeft 20 getallen in en druk de gesorteerde reeks af".

Ik wil beginnen aan de sturing van de treinbaan (die er ook nog niet is, maar dat is een ander verhaal). Dus ik ga moeten inlezen van files, inlezen van het bedieningspaneel, de beslissingen nemen en de io's sturen. Elk van die zaken op zich zie ik wel zitten. Probleem is vooral dat dit niet als een doorlopende bezigheid gaat kunnen doorgaan. Dus ik moet alles goed structureren zodat het handelbaar blijft. Maar dat heb ik nooit geleerd. Er zijn wel boeken van 500-600 pagina's maar dat is altijd weer eerst een hele uitleg van een of andere taal en dan enkele algemeenheden over datastructuren. Nooit iets over hoe degelijk opsplitsen, libraries, herbruikbaar en onderhoudbaar maken.

Alle suggesties welkom.

[oebr]

niet direct Johan.Ben daar ook al een tijdje op aan het sjikken (en ondertussen ook c++ aan het leren).
Analyse is een belangrijke stap in het ontwerpproces, dat merk je snel he.

Ik heb wel heel veel interessante boeken gevonden op http://it-ebooks.info/   
Tot voor kort kon je het gros daar ook gratis downloaden. Ik zal (zodra m'n pc gerepareerd is, gebruik nu een
laptopje met lege harde schijf :-) ) ook eens in m'n oogst zoeken of ik wat vind dat je zou kunnen helpen.

[eve]

Boeken...neen, ik ken er geen.

Wat jij wil doen heb ik zelf al wel ooit gedaan. Een werkend programma voor de besturing van een modelbaan.
Ik zie 1 enorm probleem bij u : je hebt nog geen baan !!!

Zo een programma is erg groot. Maar opgebouwd uit kleine stukjes. Je schrijft een stukje code en die code test je GRONDIG uit zodat dit stukje kan dienen als basis voor de verdere programmadeeltjes...Als je dan 2 deeltjes hebt ga je alweer testen hoe ze samenwerken, enz.

Het is hard werken en de weg is erg eenzaam.

Erik

[bellejt]

mss moet je op zoek naar het boek Digitale modeltreinbesturing van M. J. Wijfels.Daar staan voorbeelden van besturing en programmatie in .Uitgegeven door elektuur  met als isbn 90-70160-82-X.

[PeterC]

Heeft er iemand een titel van een boek over hoe je een programma schrijft?

Ik vermoed dat er niet een 'universeel' boek is, tenzij schoolboeken.  De meeste lectuur die ik ken is specifiek voor één of andere taal en begint vanf nul tot heel complex.  Zelfs voor kinderen wordt er eerst een taal gekozen en dan beginnen ze in die taal te experimenteren.
Voor mij is programmeren een soort 'kunst'.  Je kan er veel over lezen en leren maar je moet voor jezelf een manier vinden die je goed ligt, die je problemen met een minimum aan code oplost en die eventueel nog 'leesbaar' is voor anderen.

Mijn raad: kies een taal en begin eraan.  In de 35 jaar dat ik programmeer ben ik al meerdere keren van taal veranderd en of je het nu hebt over bread, brot, pain of kruh, het blijft brood en in alle talen wordt het op min of meer dezelfde manier gemaakt en verorberd.

...Ik wil beginnen aan de sturing van de treinbaan...

Waarom warm water uitvinden?

mss moet je op zoek naar het boek Digitale modeltreinbesturing van M. J. Wijfels.Daar staan voorbeelden van besturing en programmatie in .Uitgegeven door elektuur  met als isbn 90-70160-82-X.

Dat boek is ondertussen al wat decennia oud en gedateerd.  Ik heb het wel nog als pdf...

[Gerolf]

De structuur van een programma bedenk ik de laatste tijd met een ander hulpmiddel: mind-mapping (dankzij een tip van Jean "SteamN")
Programmeren zelf: Kies inderdaad een taal, en begin er mee. Stap voor stap ...

[conducteur]

Als het specifiek voor op een PC is met rekenpower in overvloed dan kun je enkele zaken gebruiken om het beheersbaar te houden.

Complexe zaken die op PC draaien -> OOP.... Alles (de gekste dingen) klassen van maken, en met objecten werken. 
Elke klasse beschrijft de werking van een deel van je programma.... Goed elke methode documenteren (Javadoc, doxygen,...).


Git kan ook een handig hulpmiddel zijn als versiebeheersysteem... Elke keer je een nieuwe functie hebt die werkt "committen", als het daarna in het honderd loopt kun je eenvoudig terugdraaien naar de vorige versie. Gebruik een Master en een develop branch. In de Master hou je de versie bij waarvan je weet dat ze betrouwbaar werkt, de develop branch gebruik je om je nieuwe ontwikkelingen in bij te houden. Kun je aanvullen met Github account als je het opensource wil. (bij interesse schrijf ik hier gerust een tuto over). Om iets op een "andere manier" te proberen kun je ook met branches enzo werken. Ik hou het meestal vrij eenvoudig...


Ik ben er geen expert in, maar in principe zou je code bij complexe projecten "loosely coupled" moeten zijn. Dat laat toe om makkelijk wijzigingen door te voeren. Misschien eens zoeken op "loosely /tightly coupled code".

[Havoc]

Ja, het is voor op een pc. Mijn kennis is beperkt tot gewone C en zo complex is het nu ook niet (denk ik).

Om een praktisch voorbeeld te nemen om de discussie wat concreter te maken, ik werk met een gekochte module die usb naar I2C, A/D en GPIO omzet (een library met basis interfacing ernaar was erbij). Dus ben ik begonnen met alles wat ik daarmee doe in een library te stoppen. Bedoeling is om die module "af te schermen" van het programma zodat wanneer die module niet meer te koop is enkel dat stuk moet herschreven worden. In theorie...

Dat leek me een logische en nuttige afsplitsing. Ook laat me dit toe om al iets te testen. Maar daar stopt het, ik zie niet direct andere punten die toelaten af te splitsen.

Ook heb ik de indruk dat ik meer ballast aan het schrijven ben dan nuttige zaken. Nu ja, "ballast" want het is bvb de voedingsspanning meten en zien of die niet teveel afwijkt alvorens de resets naar de bussen vrij te geven. Telkens de return value controleren als je iets met de module doet om te zien of je commando goed uitgevoerd is en indien nodig de foutboodschap afdrukken en afsluiten. Gewoon de usb openen en bvb de I2C instellen is enkele pagina's "rondom" een handvol commando's. Langs de ene kant lijkt dit overbodig (bretels, broekriem en stuk touw filosofie), langs de andere kant veel saai altijd hetzelfde dat nergens goed voor lijkt (waarschijnlijk tot de eerste keer dat er iets mis gaat).

Ik ga de tips die er al zijn verder bekijken. Dacht om een repository op te zetten (wel svn ipv git) maar voorlopig lijkt me dat wel heel complex vergeleken met wat er nu is. Langs de andere kant om eraan te beginnen als het programma al complex wordt is het misschien te laat.

Waarom het warm water opnieuw uitvinden? Goeie vraag met toch wel wat antwoorden (voor mij, misschien voor anderen):
- ik heb nog niets gezien dat me aanstaat. De meeste programma's gaan ervan uit dat je alles met DCC (of zoiets) doet. Wel, met de Z waarvoor dit bedoeld is gaat dat niet. Ik heb geen zin om die locs (vaak destructief) om te bouwen als er al decoders zijn.
- meeste programma's zijn ook bedoeld voor volledige automatisatie. De bedoeling is om alles te kunnen van volledige automatisatie tot "ondersteund" manueel. In dat geval doet de pc de beveiliging, leest wat ik wil vanop het bedieningspaneel en voert uit. Of laat een deel automatisch rijden en een deel manueel. (ik noem dat stationschef spelen)
- ik wil een pc maar die mag geen interface zijn. Dus niets te bedienen met toetsenbord, muis, scherm. Ik zit de hele dag achter zo'n ding en dan hoef ik het niet meer met mijn treinen. (wel ok voor op te starten alhoewel niet strict noodzakelijk)
- ben ook van opleiding electronica ontwerper (maar heb nooit software gedaan), dus dit is voor mij véél plezanter dan huisjes, boompjes, mannetjes en andere dingen

[PeterC]

Johan,
Ik meen al ergens te hebben gelezen dat je bekent bent met Linux?  In dat geval zou je volgens mij beter opteren voor een Rasperry Pi.  Die heeft I²C, GPIO en AD aan boord.  Je kan programmeren in oa C/C++ (maar moet je telkens compileren) en heel belangrijk: Python! Een interpreter taal die ook OOP toelaat.  Zet een display en wat toetsen op je Pi en je kan aan de slag.  Via VNC kan je vanop gelijk welke PC op je Pi werken. 
Bij de chinaman zijn verschillende interface boards voor 2 appels en wat eieren verkrijgbaar.
Lectuur: massa's op het net te vinden!
Succes!

[patrick smout]

Johan,

een deel van het antwoord op je vraag zijn "Architectural design patterns", google maar even op deze termen.
In principe zijn dit "best practices" m.b.t. het oplossen van veel voorkomende software ontwerp problemen.
Focus ligt op abstractie en hergebruik.

Een eenvoudig en leuk voorbeeld is dit http://www.adamtornhill.com/Patterns%20in%20C%204,%20OBSERVER.pdf
Heel herkenbaar probleem waarbij je bvb één of meerdere functies periodiek wil aanroepen op basis van een timertick.
Als de functies die aangeroepen moeten worden in een Array opgeslagen worden in de timer bibliotheek dan is de oplossing per definitie niet flexibel.
Dit voorbeeld laat zien hoe het wel moet.

Zo zijn er tientallen (embedded) design patterns.

mvg,

Patrick Smout

[patrick smout]

Johan,

misschien ook nog even dit.

Voor object georiënteerd ontwerpen (OO) van software kan je beter eerst een cursus OO doorspitten en vervolgens je toeleggen op de taal ( C++, JAVA).

Het duurt even vooraleer je het OO denken in de vingers hebt. De taal aanleren is het makkelijkste deel.
Als je direct met de taal begint is de kans reëel dat je nooit OO gaat denken/ontwerpen en dan schrijf je wel C++/JAVA programma's maar deze zijn daarom nog niet direct OO.

mvg,

Patrick

[Havoc]

Peter, het is voor onder linux. Een RPi is een optie, het programma zou mits hercompilatie gewoon moeten draaien. Ben nu ook gewoon in C bezig met CodeBlocks op de laptop. In theorie is met de goeie config ook compilatie voor Windows mogelijk, de driver voor de usb interface is daarvoor voorzien (door de fabrikant, dat is ver buiten mijn erf).

Patrick, heb het gedownload, ga dat eens lezen op de trein. Zoiets lijkt wat ik zoek. OO ben ik niet van plan. Nooit gedaan, ken het idee erachter maar om dat voor 1 toepassing ooit te gaan studeren is iets teveel denk ik. Ben vroeger wat met C bezig geweest, genoeg om de programma's die ik toen schreef nu niet meer te snappen. Vermits de lib voor de interface daarin beschikbaar is ga ik me daaraan houden. Heb ook nog de boeken etc. Dus dat moet lukken.

[Flip]

Havoc :

Er bestaan wel boeken om in een bepaalde taal te leren programmeren.
Zo ben ik ooit begonnen.
Om iets uit te testen moet je een baan hebben natuurlijk.
Verder een digitaal systeem en hier hangt veel van af hoe je commando's en terug meldingen enz  moet verwerken.
Veel digitale systemen beschikken over een zg protocol een soort handleiding om met een interface en pc te werken.
Geen klein werk . Voor mij is het een hobby in een hobby .

Gr

Flip

[ysbeer]

Echt modern ben ik niet met mijn zelf geschreven trein besturing.
Maar vuur is ook niet zo modern en we gebruiken het nog steeds.
Volgens mij gaat het er om is het niet te moeilijk en werkt het goed.
Ik gebruik power basic nu nog zonder compiler ,maar het kan wel met
Ik vind het voordeel van deze basic dat je veel (bijna alles)even snel kan proberen.
Je schrijft iets ,druk start ,en ziet meteen of het wel of niet werkt.
Bij alle (bijna)programmeer talen moet je eerst een file maken ,die omzetten naar een exe file.
Dan proberen en als het niet gaat weer terug.
Wizigen ,weer exe file ,weer proberen
Vooral als niet 100% programmeur wordt ik daar dol van (kost tijd als water)
Power basic draait onder dos (stabiel) en kan echt alles wat voor een treinbesturing nodig is
Het is trager dan b.v.C ofC++ maar snel zat voor een baan met 5 treinen tegelijk .
Wel is het zo dat mijn baan nog voor 90% analoog loopt.
Trouwens voor seinen /wissels/ e,d is digitaal sturen eigenlijk onzin en nogal duur
decoders/terugmelders tegen wat draad (reken maar uit)
wim
   

[philippe_007]

https://nl.wikipedia.org/wiki/Jackson_Structured_Programming

nog van in den tijd van toen (als ik op school zat) maar zeker nog bruikbaar....