|
|
@@ -0,0 +1,159 @@
|
|
|
+---
|
|
|
+title: "Projets, CM2"
|
|
|
+date: 2016-05-18
|
|
|
+---
|
|
|
+
|
|
|
+# Conception d’un logiciel
|
|
|
+
|
|
|
+## Quoi-qu’est-ce ?
|
|
|
+
|
|
|
+- « plan du code » (diagrammes de classes...)
|
|
|
+- au début du projet, permet de prévoir le code à écrire
|
|
|
+- pendant le projet, permet de suivre l’avancée du projet
|
|
|
+- à la fin du projet, permet de documenter le code (maintenance)
|
|
|
+
|
|
|
+$\rightarrow$ doit correspondre aux fonctionnalités prévues et au code réel
|
|
|
+
|
|
|
+## En pratique
|
|
|
+
|
|
|
+- représentation graphique + explications
|
|
|
+- si possible, utiliser un formalisme classique (UML)
|
|
|
+- utiliser plusieurs niveaux d’abstraction (vue d’ensemble, vues détaillées)
|
|
|
+
|
|
|
+## Étape de conception
|
|
|
+
|
|
|
+- étape **très importante**, à faire avant le développement
|
|
|
+- évite ”d’avoir à tout casser” au cours du développement
|
|
|
+- permet de répartir le travail et de planifier plus finement
|
|
|
+
|
|
|
+## Quelques conseils
|
|
|
+
|
|
|
+- faire simple, logique, classique (MVC, design patterns...)
|
|
|
+- granularité : ne pas trop détailler sauf si important/incertain/complexe
|
|
|
+- vérifier **a priori** que la conception permet d’implémenter les fonctionnalités prévues dans le cahier des charges
|
|
|
+
|
|
|
+
|
|
|
+# Développement d’un logiciel
|
|
|
+
|
|
|
+## Méthode pour écrire du code
|
|
|
+
|
|
|
+- comprendre le travail à faire (fonctionnalité/classe à implémenter)
|
|
|
+- découper en étapes et les ordonner
|
|
|
+- implémenter (coder, compiler, tester) étape par étape
|
|
|
+
|
|
|
+## Conseils sur le développement en équipe
|
|
|
+
|
|
|
+- faire le point régulièrement : travail fait, travail à faire
|
|
|
+- répartir le travail de façon à éviter les conflits (fichiers différents)
|
|
|
+- commits réguliers, branches si nécessaire
|
|
|
+- faire attention à respecter le cahier des charges et la conception
|
|
|
+
|
|
|
+## Programmation en binômes
|
|
|
+
|
|
|
+- principe :
|
|
|
+ - un secrétaire + un relecteur **sur une même machine**
|
|
|
+ - les deux participent activement
|
|
|
+ - changer les rôles fréquemment
|
|
|
+- intérêts :
|
|
|
+ - moins d’erreurs
|
|
|
+ - réflexions complémentaires
|
|
|
+ - motivation, convivialité (ou pas, mais bon...)
|
|
|
+- à utiliser quand le travail n’est pas complètement trivial (donc tout le temps pour les projets L3)
|
|
|
+
|
|
|
+## Tests unitaires
|
|
|
+
|
|
|
+- souvent : test « avec un printf » $\rightarrow$ pas bien
|
|
|
+ - principe des tests unitaires :
|
|
|
+ - écrire des petites fonctions de test en même temps que le code
|
|
|
+ - compiler toutes les fonctions de test dans un programme de test
|
|
|
+ - exécuter le programme de test
|
|
|
+ - vérification et non-régression automatiques
|
|
|
+- attention : détection d’erreurs $\neq$ preuve
|
|
|
+
|
|
|
+$\rightarrow$ à utiliser pour les modules de base (traitement de données) voire plus
|
|
|
+
|
|
|
+## Programmation par pseudo-code
|
|
|
+
|
|
|
+- principe :
|
|
|
+ - commencer par écrire le pseudo-code de l’algo en commentaire
|
|
|
+ - traduire chaque ligne de pseudo-code en code réel
|
|
|
+ - laisser le pseudo-code en commentaire
|
|
|
+- intérêt :
|
|
|
+ - code plus facile à écrire
|
|
|
+ - code plus facile à relire
|
|
|
+
|
|
|
+$\rightarrow$ très utile quand le code à écrire n’est pas trivial
|
|
|
+
|
|
|
+## Gestion d’erreurs
|
|
|
+
|
|
|
+- assertions
|
|
|
+- logs
|
|
|
+- codes de retour, variables d’état
|
|
|
+- exceptions
|
|
|
+
|
|
|
+$\rightarrow$ problème difficile
|
|
|
+
|
|
|
+$\rightarrow$ se mettre d’accord sur la façon de faire au début du projet
|
|
|
+
|
|
|
+## Conventions de code
|
|
|
+
|
|
|
+- formatage du code, nommage des variables...
|
|
|
+- conventions à définir et à respecter au niveau du projet
|
|
|
+- permet d’avoir un code plus facile à lire
|
|
|
+- utiliser des conventions classiques ou les expliciter dans la documentation
|
|
|
+
|
|
|
+## Exemple de conventions de code C++
|
|
|
+
|
|
|
+- notation dromadaire
|
|
|
+- un nom de classe commence par une majuscule :
|
|
|
+```cpp
|
|
|
+class Event ...
|
|
|
+```
|
|
|
+- préfixe _ pour les attributs :
|
|
|
+```cpp
|
|
|
+std::string _summary ;
|
|
|
+```
|
|
|
+- préfixe ptr pour les pointeurs :
|
|
|
+```cpp
|
|
|
+icalcomponent * _ptrIcal ;
|
|
|
+```
|
|
|
+- un nom de fonction commence par un verbe :
|
|
|
+```cpp
|
|
|
+void updateDataFromIcal();
|
|
|
+icalcomponent * getPtrIcal() const ;
|
|
|
+```
|
|
|
+- maximum 80 caractères par ligne
|
|
|
+- ...
|
|
|
+
|
|
|
+## Quelques outils de développement à décider
|
|
|
+
|
|
|
+- langages, bibliothèques...
|
|
|
+- outils de compilation, test, déploiement
|
|
|
+- outils de gestion de code source (git, svn...)
|
|
|
+- outils de gestion de projets (github, redmine, trac, sourceforge...)
|
|
|
+
|
|
|
+
|
|
|
+# Gestion de code source avec git
|
|
|
+
|
|
|
+TODO
|
|
|
+
|
|
|
+
|
|
|
+# Gestion de projets avec github
|
|
|
+
|
|
|
+TODO
|
|
|
+
|
|
|
+
|
|
|
+# Travail à réaliser
|
|
|
+
|
|
|
+## Au début du projet
|
|
|
+
|
|
|
+- créez des comptes et un dépôt sur [github](https://github.com)
|
|
|
+- faire une conception prévisionnelle du logiciel
|
|
|
+- faire un planning prévisionnel (et les tickets correspondant sur github)
|
|
|
+
|
|
|
+## Tout au long du projet
|
|
|
+
|
|
|
+- utiliser git pour réaliser le projet (code, documentations, cahier des charges...)
|
|
|
+- utiliser github pour suivre le déroulement du projet
|
|
|
+- faire le point régulièrement pour mettre à jour la conception du logiciel et la répartition du travail
|
|
|
+
|
Julien Dehos