[C] architectuur design aanpak voor non-OO taal?

[Ixje]

Voor mijn afstudeeropdracht moet ik straks in C software maken voor een stukje open hardware. Nu heb ik tijdens mijn studie alleen maar software leren ontwerpen i.c.m. OO-talen door gebruik te maken van o.a. UML (use-cases/klassediagrammen/sequence diagrammen etc). Ik ben mij vast aan het oriënteren op mogelijke gestructureerde aanpakken voor niet OO-talen, maar loop al vrij snel vast.

Wat voor technieken heb je voor het ontwerpen van een architectuur voor een embedded systeem in een non-OO taal als C? Het (voor mij) gebruikelijke klassediagram valt al af omdat er geen klassen zijn, maar wat blijft er dan over?

Elke hint/tip is welkom!

Alvast bedankt.

[BalusC]

Zie het als 1 grote klasse. Denk in functies/methoden.

[Gorion3]

Daarnaast kan je het nog een beetje "OO" houden door met structs te werken.

[Ixje]

Gorion3 schreef op zondag 28 december 2008 @ 14:42:
Daarnaast kan je het nog een beetje "OO" houden door met structs te werken.

Ik had inderdaad gevonden dat je het m.b.v. structs nog aardig OO kon maken. Waar ik vooral naar opzoek ben is hoe ik dit dan weer overzichtelijk in kaart breng, want officieel kan je het weer geen klassen noemen en dus geen klassediagram maken.

Je zou toch verwachten dat er vanuit de embedded software industrie ook een of andere 'standaard' is die beschrijft hoe de architectuur wordt ontworpen en getoond zoals je use-cases/klassediagrammen en sequence diagramen gebruikt voor de 'normale' software systemen. Ik heb het echter alleen nog niet kunnen vinden .

[Exirion]

Ik wil je niet persoonlijk aanvallen, maar ik zou eens heel hard gaan klagen bij je school als je bij je afstuderen nogsteeds niet verder komt dan ontwikkelen met strict gestructureerde oplossingen. Ik vind dit weer een mooi voorbeeld van de ellende die wordt aangericht door mensen alleen nog maar Java of hoogstens C++ te leren.

Ik zou gewoon eens een boekje over C gaan doorbladeren Moeilijk zal het niet echt voor je zijn.

[MLM]

je kan OO faken door structs te maken met een naam en dan functies die beginnen met die naam, dan is het nog een beetje leesbare code:

C:

typedef struct
{
  //members
} foo;

//functies die foo gebruiken
foo *foo_create(void);
void foo_destroy(foo *);
void foo_do(foo *, some_argument);

maar je kan dan niet echt mooie diagrammen maken

Wat ik je aanraad is om gewoon C en C++ te mixen, link gewoon je C libraries voor je hardware in je C++ programma, en schrijf een wrapper class in C++

Er is bijna niets wat je niet in C++ kan doen wat wel in C kan, enige vereiste is dat je een compiler hebt voor je architectuur

[KopjeThee]

Zoek eens in deze hoek. Abstract data type.

[.oisyn]

Waarom kun je met structs in hemelsnaam geen diagrammen maken? Er is in feite niets veranderd. Of hebben jullie het over automatisch gegenereerde code uit de diagrammen of andersom?

[Wiebbe]

Ik denk dat het meer is dat het niet "mag" volgens de "wetten" van UML of school of iets dergelijks. Maar je moet diagrammen gewoon gebruiken om dingen in kaart te brengen. Of je dat nou met UML of met de hand tekent, het punt is dat je er van te voren over na hebt gedacht

[Verwijderd]

Wat moet je precies maken? Draaien er een berg communicerende processen / sub-processen? Kijk dan eens naar de hatley pirbhai ontwerp methode. Verder kun je inderdaad prima je diagrammen maken voor strucks.

[Ixje]

Exirion schreef op zondag 28 december 2008 @ 15:32:
Ik wil je niet persoonlijk aanvallen, maar ik zou eens heel hard gaan klagen bij je school als je bij je afstuderen nogsteeds niet verder komt dan ontwikkelen met strict gestructureerde oplossingen. Ik vind dit weer een mooi voorbeeld van de ellende die wordt aangericht door mensen alleen nog maar Java of hoogstens C++ te leren.

Ik zou gewoon eens een boekje over C gaan doorbladeren Moeilijk zal het niet echt voor je zijn.

Ik voel me zeker niet persoonlijk aangevallen hoor. Het probleem ligt hem in dat ik een opleiding tot software engineer volg. De focus van deze opleiding ligt vooral op thin/fat client software i.c.m. databases. Ik heb er zelf voor gekozen om voor mijn afstudeer project iets met hardware programmeren te gaan doen omdat ik daar een uitdaging in zie.

Echter weet ik dat ze het tijdens mijn afstuderen het proces tot het product heel belangrijk vinden, waar het modelleren van het systeem op zich zelf al voor ~40% telt. Normaal gooi je er dus een een beetje prince2/RUP en UML tegen aan en dan zit je goed. Nu zoek ik gewoon een alternatief voor het klassediagram (binnen of buiten UML om).

[Ixje]

KopjeThee schreef op zondag 28 december 2008 @ 16:17:
Zoek eens in deze hoek. Abstract data type.

Dank u. Ik zal er eens naar kijken.

[Ixje]

Wiebbe schreef op zondag 28 december 2008 @ 19:00:
Ik denk dat het meer is dat het niet "mag" volgens de "wetten" van UML of school of iets dergelijks. Maar je moet diagrammen gewoon gebruiken om dingen in kaart te brengen. Of je dat nou met UML of met de hand tekent, het punt is dat je er van te voren over na hebt gedacht

Tja zie het inderdaad een beetje als de wetten van school. Met UML kan je makkelijk de architectuur van je systeem tonen en terug redeneren hoe deze voldoet aan de eisen van je opdrachtgever.

.oisyn schreef op zondag 28 december 2008 @ 18:57:
Waarom kun je met structs in hemelsnaam geen diagrammen maken? Er is in feite niets veranderd. Of hebben jullie het over automatisch gegenereerde code uit de diagrammen of andersom?

Diagrammen kan je overal van maken. Het gaat hem alleen meer om wat Wiebbe hierboven al zei "wetten van school". Ik hoopte gewoon dat er al een bestaand en redelijk de facto iets zou zijn zoals UML voor OO-talen is wat ze vanuit school weer mooi vinden.

Verwijderd schreef op zondag 28 december 2008 @ 19:03:
Wat moet je precies maken? Draaien er een berg communicerende processen / sub-processen? Kijk dan eens naar de hatley pirbhai ontwerp methode. Verder kun je inderdaad prima je diagrammen maken voor strucks.

Een deel van wat ik moet maken is een implementatie van een NFC protocol.

Bedankt voor je hatley pirbhai tip, ik ga er wat over zoeken

[Johnny]

UML bevat veel meer soorten diagrammen dan alleen een klassediagram. Je kan gewoon een Activity of State diagram gebruiken, maar ook buiten UML bestaan er nog een hoop andere modelleertalen, bijvoorbeeld het Data Flow diagram en nog veel meer.

[Zoijar]

Geen verschil. In UML beschrijf je het systeem dat je op gaat zetten; dat vertaal je vervolgens naar een programmeer taal. Of dat nou C, C++, Java of SQL is.

[RobIII]

offtopic:
Ixje: Meerdere posts achter elkaar is niet gewenst hier; als je nog iets wil toevoegen aan je post kun je de edit knop gebruiken ( ) en dan schop je je topic niet onnodig telkens omhoog (zie ook topickick binnen 24 uur)

[prototype]

Zoals eerder gezegd, als C++ echt je voorkeur geniet, schrijf dan zoveel mogelijk daar in en extern dan een interface naar C zodat de linker 't gewoon met je C code kan linken onder de C convention (andersom kan natuurlijk ook, C code gebruiken in C++ code). Desnoods schrijf je het in C++ en laat je een compiler het naar C compilen zoals dat "vroegah" veelal gebeurde. ;-)

Voor de rest modeleer je met UML je systeem, maar zie ik niet hoe je dit (op een OO wijze) niet kan implementeren met C. Zoals al eerder gezegd, class diagrams worden vaak gebruikt ook om databases te modeleren, maar daar zie je toch ook geen "class mechanisme"? En toch lijkt dit prima te kunnen ;-)

Met structs moet je prima uit de voeten komen. Ter illustratie, een OO taal als objective-C is niks anders dan een thin layer bovenop C waarbij kort door de bocht de state ook opgeslagen wordt in structs en doorgespeeld wordt naar functies: als je de naar-C-gecompileerde code bekijkt, dan begrijp je misschien beter dat OO prima kan. Je moet niet de vergissing maken dat OO niet kan omdat je mechanismen als classes mist... OO is een paradigm, een denk model if you will :-) Een OO taal geeft je simpelweg meer mechanismen die het eenvoudiger maken om volgens het OO model te implementeren -- zie ook Stroustrup's definitie van een OO taal.

[ Voor 9% gewijzigd door prototype op 29-12-2008 11:09 ]

[H!GHGuY]

En om de mensen hierboven bij te treden:

Zowel C als C++ worden naar assembly gecompileerd, dus er is niets dat je in C niet kan wat in C++ wel kan.
De taal kan het je alleen maar gemakkelijker maken.

Wil je echt OO in C zien kijk dan even naar de Linux kernel. Deze is over het algemeen behoorlijk OO opgezet en is toch volledig in C.

Gemakkelijke plaatsen om te beginnen zijn bijvoorbeeld drivers/i2c of drivers/spi.

[.oisyn]

H!GHGuY schreef op maandag 29 december 2008 @ 11:24:
Zowel C als C++ worden naar assembly gecompileerd, dus er is niets dat je in C niet kan wat in C++ wel kan.

Dit is op zichzelf een onzinredenatie. Het is niet dat omdat ze allebei naar asm worden gecompiled je met allebei hetzelfde kan. Alle uitvoerbare code kan gecompileerd worden naar asm, daar hoeft een taal niet eens turing-complete voor te zijn. Maar als die taal niet turing-complete is, dan kun je er niet hetzelfde mee als in C of C++.

Maar wat ook gedaan wordt, is C++ code compileren naar C code. De comeau C++ compiler doet dat bijvoorbeeld, zodat je automatisch op erg veel platforms een goede fully compliant C++ compiler tot je beschikking hebt. Alleen wil je niet weten wat voor lelijke code dat oplevert ivm het gebruik van exceptions.

[prototype]

.oisyn schreef op maandag 29 december 2008 @ 11:38:
[...]

Dit is op zichzelf een onzinredenatie. Het is niet dat omdat ze allebei naar asm worden gecompiled je met allebei hetzelfde kan. Alle uitvoerbare code kan gecompileerd worden naar asm, daar hoeft een taal niet eens turing-complete voor te zijn. Maar als die taal niet turing-complete is, dan kun je er niet hetzelfde mee als in C of C++.

Als we 't dan toch over turing completeness hebben, niet alleen C++, maar C++'s template systeem is al turing complete. M.a.w. C++ templates system is al turing equivalent met C. Het compilatie process vindt namelijk plaats op niet enkel een probleem beschrijving maar door een programma wat inhoudt dat je dus daar ook te maken kan hebben al met het halting probleem. In theorie kun je dus niet zeker ervan zijn of je wel te maken hebt met een valid C++ programma als gevolg ervan ;-) Tot zover brainmasturbation-and-unlikely-things 101!

[H!GHGuY]

.oisyn schreef op maandag 29 december 2008 @ 11:38:
[...]

Dit is op zichzelf een onzinredenatie. Het is niet dat omdat ze allebei naar asm worden gecompiled je met allebei hetzelfde kan. Alle uitvoerbare code kan gecompileerd worden naar asm, daar hoeft een taal niet eens turing-complete voor te zijn. Maar als die taal niet turing-complete is, dan kun je er niet hetzelfde mee als in C of C++.

Maar wat ook gedaan wordt, is C++ code compileren naar C code. De comeau C++ compiler doet dat bijvoorbeeld, zodat je automatisch op erg veel platforms een goede fully compliant C++ compiler tot je beschikking hebt. Alleen wil je niet weten wat voor lelijke code dat oplevert ivm het gebruik van exceptions.

Misschien moet ik specifieker zijn in mijn onzinredenatie

Als je een C++ member functie omzet naar een C 'member' functie dan doe je

C++:

X Class::MemberFn(Y y, Z z)
{

}

C:

X MemberFn(Class* this, Y y, Z z)
{

}

Met wat abstractie is dit ook precies wat je compiler doet. Python is zelfs zo lame (pardon my french ) om de gebruiker dit expliciet te laten doen.

Beide stukjes code zijn equivalent en zullen slechts "beperkte" verschillen opleveren in asm.

Dat is dus wat ik bedoelde met "Ze worden toch beiden naar asm gecompiled, dus je kan er hetzelfde mee. Alleen maakt de taal (C++ in dit geval) het iets makkelijker dan C".

[EXX]

H!GHGuY schreef op maandag 29 december 2008 @ 11:24:
Zowel C als C++ worden naar assembly gecompileerd, dus er is niets dat je in C niet kan wat in C++ wel kan.
De taal kan het je alleen maar gemakkelijker maken.

offtopic:
Hehe, dit doet me denken aan een uitspraak van een medestudent tijdens mijn HTS studie: "Alles kan in Assembly, dus al die andere dingen als BASIC en Pascal heb je niet nodig".

Die gast schreef dus alle software voor zijn TRS-80 Model 4 in Assembly. Tekstverwerkers, rekenprogsels, you name it.

[Zoijar]

EXX schreef op maandag 29 december 2008 @ 12:07:

offtopic:
Hehe, dit doet me denken aan een uitspraak van een medestudent tijdens mijn HTS studie: "Alles kan in Assembly, dus al die andere dingen als BASIC en Pascal heb je niet nodig".

Die gast schreef dus alle software voor zijn TRS-80 Model 4 in Assembly. Tekstverwerkers, rekenprogsels, you name it.

offtopic:
Heb ik ook een jaar of 4 volgehouden Een betere opleiding is er haast niet; daarna is alles makkelijk.

[MSalters]

Weinig off-topic aan; als je serieus met hardware bezig gaat zijn dan is kennis van assembly een goed idee. Waar een assembly programmeur met een 8 bits AVR microcontroller toe kan, heeft een OO progammeur al gauw een 16 bits microcontroller nodig. Die schelen nogal in prijs.

[farlane]

MSalters schreef op dinsdag 30 december 2008 @ 00:08:
Die schelen nogal in prijs.

Inmiddels is het zo dat de 8 en 32 bitters behoorlijk naar elkaar toe kruipen qua prijs; het zal denk ik niet lang meer duren totdat de 8 bitters duurder gaan zijn.

[MSalters]

Weet je't zeker? Een kleine 8 bit AVR kost je misschien 50 cent, een 32 bits ARM 2-3$. Dat is dus een factor 5 prijsverschil. (e.e.a. bij volumedeals, maar dat leek me in context duidelijk - bij kleine aantallen domineert de prijs van software onwikkeling)

[farlane]

MSalters schreef op dinsdag 30 december 2008 @ 18:17:
Weet je't zeker? Een kleine 8 bit AVR kost je misschien 50 cent, een 32 bits ARM 2-3$. Dat is dus een factor 5 prijsverschil. (e.e.a. bij volumedeals, maar dat leek me in context duidelijk - bij kleine aantallen domineert de prijs van software onwikkeling)

In het segment waar je 8 digitale I/O nodig hebt zal de 8 bitter wel goedkoper blijven vermoed ik ( daar zit die 50c uP ongeveer ) , maar met de telkens hogere eisen die worden gesteld aan embedded spul zie ik niet veel toepassingsgebieden overblijven. Altans, dat is de tendens die ik zelf meen te zien.

[abort_]

Zoals al eerder vermeld zijn structs aardige vervangers voor classes. Je kunt alleen geen functions in de struct maken zoals bij een class (wel in C++). Hierdoor zijn alle member variablen dus ook direct public. Verder zou ik het houden op een aantal losse source files. Via methode benamingen (zoals: server_listen en server_accept) kom je ook wat meer in de richting van OO.

Correct me if I'm wrong.

[bobo1on1]

Je kunt wel een method emuleren met een functiepointer in een struct.

[.oisyn]

Nee, want je moet alsnog de thispointer meegeven anders weet de "method" niet voor welke instance hij werkt. Je kunt dat wel weer gebruiken voor virtual methods.

[ Voor 19% gewijzigd door .oisyn op 31-12-2008 20:15 ]

[bobo1on1]

Mja, natuurlijk moet je die pointer meegeven, ik beweer ook helemaal niet dat je dat niet moet doen.

Ik moet wel zeggen dat een functiepointer op die manier gebruiken de boel niet echt overzichtelijk maakt, je hebt er imho ook geen reet aan behalve dat het leuk staat.

[Zoijar]

bobo1on1 schreef op woensdag 31 december 2008 @ 20:50:
Mja, natuurlijk moet je die pointer meegeven, ik beweer ook helemaal niet dat je dat niet moet doen.

Ik moet wel zeggen dat een functiepointer op die manier gebruiken de boel niet echt overzichtelijk maakt, je hebt er imho ook geen reet aan behalve dat het leuk staat.

Natuurlijk is dat wel nuttig; het geeft een extra level of indirection. Elk probleem in de informatica kan opgelost worden met een extra level of indirection Linux kernel gebruikt dit truckje ook veelvuldig.

[H!GHGuY]

Zoijar schreef op donderdag 01 januari 2009 @ 08:31:
[...]

Natuurlijk is dat wel nuttig; het geeft een extra level of indirection. Elk probleem in de informatica kan opgelost worden met een extra level of indirection Linux kernel gebruikt dit truckje ook veelvuldig.

Juist. Een plaats waar dit goed tot zijn recht komt is bvb de socket code (net/core en net/ipv4 voor de gekendste protocollen). Daar worden ook defaults voorzien die dan overschreven worden voor TCP receives etc.

[farlane]

Zoijar schreef op donderdag 01 januari 2009 @ 08:31:
Elk probleem in de informatica kan opgelost worden met een extra level of indirection

Je vergeet het gedeelte "except too many levels of indirection"

[Zoijar]

hehe juist