Re: [gentoo-user-fr] [HS] Gérer un projet en C

[Laurent Steffan]

Salut,

Le 07.12.2005 07:06, grillot sebastien a écrit :
> (re)bonjour,
> Voila enfin un vrai HS de chez HS ;)

Ahhhh! ça nous manquait

> Comme je l'ai deja dis, notre association va participer à la coupe de
> france de robotique. Pour ce faire nous allons coder notre bestiolle
> en C. C'est une grande premiere pour moi de travailler en C sur un
> projet aussi "important" et sur de l'electronique (enfin un truc
> different d'une gestion_de_je_sais_pas_quoi comme nous pouvons faire
> en BTS IG par exemple :).
>
> Alors voila, j'ai pas mal de question :
> - Comment peut-on analyser le code que nous aurons à produire? Par

Avant même de commencer à "analyser", il faut faire une liste de ce que 
vous voulez faire, en terme de fonctions (les besoins étant supposés 
connus...).

Est-ce que l'architecture matérielle du robot (au sens électronique) est 
déjà décidée ? parce que dans les systèmes embarqués il y a souvent des 
compromis entre matériel et logiciel, et si on fige le matériel on 
écarte implicitement certaines solutions. D'un autre côté, la conception 
est beaucoup plus simple.

> quoi devons nous commencer. Je suis un habitué du systeme MERISE pour
> analyser les besoins. Dans notre ecole on nous parle tout le temps
> d'UML. Mais ne devrais-je pas simplement decouper mon projet en
> fonction des differents PIC que je vais avoir sur ma bestiolle ? De
> plus, nous allons avoir un GNU/Linux qui fera tourner un ARM (Gumstix
> ou routeur asus) pour le traitement de l'image et "l'inteligence" du
> robot.

UML est quand même très orienté objet, je ne sais pas si c'est vraiment 
utile pour faire du C. D'autant qu'un gros intérêt d'UML est la 
génération automatique de code, et je ne suis pas sûr que ça génère du 
C... Ceci dit, tu peux au moins exploiter les "use cases" pour exprimer 
les besoins.

Merise en général est plutôt utilisé pour décrire les données, je ne 
l'ai jamais vu utilisé pour des systèmes temps réel ou embarqués (bien 
sûr ça veut pas forcément dire grand chose).

> De plus, je decouvre tout les outils (lclint, gprof...) pour analyser
> le code. Comment dois-je travailler avec ce genre d'outils, à chaque
> fois que j'ai terminé d'ecrire une fonction, à chaque fois que je
> viens de coder un "mouvement" dans mon robot, à la fin de chez la fin?
> Je presume que si c'est à la fin il faut absoluement se prevoir un
> "délais" pour ne faire que ca. L'audit du code doit se faire par la
> personne qui à codé, par quelqu'un d'autre ? Est-ce reelement une
> etape utile, sachant que je penses que oui car le systeme se
> retrouvera embarqué donc dans des limites importantes...

De façon plus générale, il faut choisir une méthode de développement 
avant tout, et choisir ensuite les outils adaptés. Un exemple : est-ce 
que vous serez plusieurs à coder ? si c'est le cas, il est presque 
certain qu'il vous faudra un système genre CVS.

C'est le test qui est la partie la plus importante pour un système temps 
réel ou embarqué (au fait, tu situes votre robot dans quelle catégorie? 
juste pour avoir une idée des contraintes). A ce sujet, je recommande 
chaudement l'optique "Test Driven Development" (TDD) de Kent Beck, qui 
fait partie des techniques popularisées (enfin, plus ou moins ;-) ) par 
le Agile Programming (notamment Extreme Programming). Il faut pour tirer 
parti des tests les écrire dès que possible (certains disent, avant même 
d'écrire le code, et j'applique moi-même cette règle) et les faire 
passer avec un système adapté. Pour les tests unitaires je recommande 
CUnit (http://cunit.sourceforge.net). Au passage, je signale que TDD est 
une méthode de développement, pas seulement de test.

Les outils comme lclint, splint, doivent généralement être utilisés du 
début à la fin. Le mot-clé étant "début". Pour le "profiling", mon point 
de vue c'est que pour du temps réel si on n'a pas des performances 
suffisantes *avant* le profiling on n'a aucune chance d'y arriver : le 
plus critique pour les performances en effet c'est souvent 
l'architecture globale (communication inter-tâches, etc.)

Quant à l'audit du code, il est recommandé de le faire, mais là encore 
les méthodes sont différentes selon les gens. Dans tous les cas, l'audit 
doit être fait par une personne qui n'a pas codé. Il peut être plus ou 
moins formalisé (réunions de revue de code, discussions avec le 
partenaire dans le cas du "peer programming", etc.).

Bon j'arrête, sinon je sens que je vais soûler tout le monde. Mais enfin 
aussi quelle idée de poser des questions sur des sujets intéressants! :-D

> Si vous avez des remarques, des questions, des idées... je vous en
> pris, lachez vous ;)

Je crois que c'est fait.

Amitiés,
Laurent



-- 
gentoo-user-fr@g.o mailing list