Phase 1, Introduction

But de ces séances

  • Organiser l’activité de développement
  • La tâche de traduction des scénarios en un programme de travail détaillé est
    • très importante,
    • difficile et nouvelle pour vous,
    • et peut avoir des conséquences lointaines et difficiles à gérer
  • Notre intention avec ces ateliers est de:
    • introduire par l’exemple les notions
    • vous aider à démarrer
    • vous sensibiliser à tout ce qui peut coincer plus tard
    • vous donner une liste claire de ce qui est à rendre

Programme

  1. GL1: cette séance, familiarisation avec les notions de schéma d’architecture et de découpage en modules pour vous préparer au PAN1
  2. GL2: retour sur votre travail d’architecture et travail sur les interfaces entre vos modules.
  3. GL3: test, debug, logs…

Définitions

  • Scénario: description textuelle de ce que font les utilisateurs avec votre projet, décrivant les principales actions en détail (jusqu’à une page A4)
  • Diagramme d’architecture: diagramme avec des boites représentant les fonctions de bases (modules) et des flêches représentant les flots de données
    • très important pour la structuration équilibrée du projet
    • la compréhensibilité plus importante que la perfection
    • support de la cohérence du groupe
  • Storyboard: des dessins, même très brouillons et à la main, donnant une idée du contenu de tous les écrans de votre application / interface utilisateur (s’il y en a une)

Votre challenge

  • Point de départ: le scénario
  • Point d’arrivée:
    • un découpage en blocs qui correspondent aux modules PACT avec un expert par module qui a accepté de vous encadrer, autrement dit un tableau avec les modules, les experts, les participants aux modules.
    • un schéma en blocs qui soit clair pour vous et clair pour le jury, avec dans ce schéma des flêches pour figurer les échanges de données
    • une documentation textuelle pour le schéma en bloc
    • s’il y a une interface graphique, un storyboard
  • Notes:
    • les documentations textuelles peuvent être succintes dans un premier temps
    • tous les éléments du schéma doivent être décrits en texte.
    • si vous ne savez pas quoi écrire, alors il y a un problème à creuser

Objectifs et contraintes

  • Objectifs
    • Faire progresser votre compréhension du projet
    • Couvrir tout votre scenario
    • Se mettre d’accord dans l’équipe / contrat
    • Répartir le travail entre toute l’équipe
    • Communiquer clairement ce que vous voulez faire au jury
    • Prouver au jury que votre réflexion est complète / poussée
  • Contraintes
    • Deux modules par personne, ou un gros module (risque)
    • Pas deux modules avec le même binôme
    • Ajouter un module Tests et Intégration
    • Note: le module SES est pour tout le groupe

Pour commencer, des exemples

Voici des exemples avec un dispositif pour stimuler l’attention.

Je vais vous montrer un schéma pendant 1mn30. Vous ne prenez pas de notes.

  • essayez de lire le schéma
  • identifiez les différents éléments du diagramme
  • découvrez les règles de base de construction
  • trouvez des défauts

Puis une pause de 30s.

Puis une prise de notes de 2mn.

Puis un débat sur ce que vous avez vu.

Prêts ?

Architecture

Pause évocative 30s

Imaginez vous le schéma. Qu’avez-vous vu ? Elements ? Lisible ou pas ?

Prise de notes 2mn

Echanges

  • Exercice (rappel):
    • identifiez les différents éléments du diagramme
    • découvrir les règles de base de construction
    • trouvez des défauts
    • identifiez ce qui vous sera utile dans votre projet et ce qui le sera moins ou pas du tout

Correction

  • pas de légende
  • ++ regroupement de bouts dans différents appareils mais même module par des pointillés

Architecture

Pause évocative 30s

Prise de notes 2mn

Echanges

  • Exercice (rappel):
    • identifiez les différents éléments du diagramme
    • découvrir les règles de base de construction
    • trouvez des défauts
    • identifiez ce qui vous sera utile dans votre projet et ce qui le sera moins ou pas du tout

Correction

  • Application Android et PC ne sont pas au même niveau, il faudrait Mobile Android et PC
  • Les flêches de couleurs (légendées) sont très claires

Storyboard

Pause évocative (30s)

Prise de notes (3mn)

Echanges (<10mn)

  • Exercice (rappel):
    • identifiez les différents éléments du diagramme
    • découvrir les règles de base de construction
    • trouvez des défauts
    • identifiez ce qui vous sera utile dans votre projet et ce qui le sera moins ou pas du tout

Correction

  • bien dans l’ensemble
  • inutile de reprendre le dessin à l’ordinateur: ça prend trop de temps et n’est pas très utile

Storyboard suffisant

Etude de cas

Nous allons dérouler ensemble une étude de cas sur:

  • Un vélo d’appartement sur lequel, pendant qu’on fait de l’exercice, on peut se balader virtuellement dans une ville comme avec Google Streetview. Le défilement du paysage suit la vitesse de pédalage et la direction du guidon. La vue suit l’orientation de la tête.

Action: débat, comment feriez-vous ?

Matériel

  • un vélo d’appartement
    • avec un capteur de “vitesse”
    • avec un capteur sur le guidon
  • un capteur d’orientation de la tête
  • un dispositif de visualitation (lunettes, HUD)
  • un ordinateur pour le contrôle général

Echanges

  • La capture de vitesse peut donner
    • une impulsion à chaque tour de roue/pédale
    • une tension proportionnelle à la vitesse
    • une information numérique de vitesse
  • Le guidon peut donner
    • une information droite-gauche-centre
    • un angle analogique ou une information numérique
  • Le gyroscope donne des informations numériques
    • connection USB
  • Les lunettes ressemblent à une paire d’écrans
    • connection VGA

Matériel supplémentaire

Ca, vous ne pouvez pas le deviner. C’est en discutant avec le spécialiste des capteurs qu’il vous dira comment le capteur peut envoyer des informations jusqu’à l’ordinateur ou le mobile…

  • Microcontroleur ou Arduino
    • numériser les informations analogiques de vitesse et du guidon

Logiciel

  • Entrées
    • information de vitesse
    • information de direction du guidon
    • information d’orientation de la tête
    • informations visuelles à adapter
  • Sortie
    • image du paysage qui défile

Logiciel

Logiciel 2

Etude des échanges

  • Affichage fluide dans les lunettes: 25 images/s
  • Vitesse vélo:18 km/h (5m/s)
  • Une image tous les 20cm ?
  • Streetview: une image tous les 10m~

➠ Echec…

  • Streetview ne marche pas
  • Autre source possible: une vidéo
    • guidon inutile

Etude de cas B

  • Google bike
  • Un vélo d’appartement sur lequel, pendant qu’on fait de l’exercice, on peut se balader virtuellement dans une ville comme avec Google Streetview. Le défilement du paysage suit la vitesse de pédalage et la direction du guidon. La vue suit l’orientation de la tête.

Matériel B

  • un vélo d’appartement
    • avec un capteur de “vitesse”
    • avec un capteur sur le guidon
  • un capteur d’orientation de la tête
  • un dispositif de visualitation (lunettes, HUD)
  • un ordinateur pour le contrôle général

Echanges B

  • La capture de vitesse peut donner
    • une impulsion à chaque tour de roue/pédale
    • une tension proportionnelle à la vitesse
    • une information numérique de vitesse
  • Le guidon peut donner
    • une information droite-gauche-centre
    • un angle analogique ou une information numérique
  • Le gyroscope donne des informations numériques
    • connection USB
  • Les lunettes ressemblent à une paire d’écrans
    • connection double VGA

Matériel supplémentaire B

  • Microcontroleur
    • numériser les informations analogiques de vitesse et du guidon

Logiciel B

  • Entrées
    • information de vitesse
    • information de direction du guidon
    • information d’orientation de la tête
    • informations visuelles à adapter
  • Sortie
    • image du paysage qui défile

Logiciel 1b

Logiciel 2b

Estimation de complexité

  • Gestion de la position: facile
  • Extraction de la vue: facile
  • Interpolation de trame: difficile → expert
    • décodage de la video
    • interpolation entre deux trames voisines quand le mouvement de la camera est plus rapide que le vélo virtuel
  • Retours d’expert:
    • interpolation de trame = module ++ mais OK
    • besoin d’un flux de position des trames de la vidéo
    • besoin d’une adaptation entre les données brutes du gyroscope et l’extraction de vue

Logiciel 3b

Echanges détaillés

  • vitesse: un clic toutes les 0.5s environ
  • position: besoin d’une estimation de progression toutes les 40ms
    • OK sauf au début
  • video HD 25im/s à décoder
  • reconstruction de la progression de la caméra:
    • préparée à l’avance ou au vol
  • extraction de la vue: une image VGA à 25 im/s

Fin de l’étude de cas

Passons à votre projet.

Comment faire

C’est un travail progressif, itératif, toutes les pistes sont bonnes pour avancer.

La suite, c’est ma façon de faire, ce n’est pas “la bonne”, c’est juste une façon qui marche pour moi.

Comment faire 1

  1. Faites la liste des éléments matériel du projet
    1. ordinateur(s)
    2. téléphone ou tablette ➡ module Android
    3. capteurs ➡ module capteurs
    4. kinect ou leap ➡ module Kinect ou Leap
    5. camera ➡ un des modules image
    6. microphone ➡ un des modules audio
  2. S’il y a plusieurs appareils qui communiquent ➡ communication Client-Serveur

Action: faire un premier jet avec tous les éléments, en individuel 10mn

Action: mise en commun et élaboration d’un premier jet de groupe, 10mn

Présentation aux autres groupes: 5 x 2mn

Comment faire 2

Faites la liste des liens entre les matériels, la liste des échanges

Exemples d’échanges: - un chiffre (ou +) - une chaine de caracteres (ou +) - un fichier texte - un objet JSON - une image - une video - …

Action: faire une première liste des échanges, identifier les gros transferts, 10mn

Comment faire 3

Faites la liste des éléments logiciels que vous avez identifié 1. Identifiez l’appareil qui vous parait celui qui executera le logiciel (ça pourra changer) et créer une sous-boite dans la boite de l’appareil pour l’élément logiciel 1. Mettez des liens entre les sous-boites pour tous les échanges

Action: 10 mn

Bilan: ou en êtes vous dans la compréhension du découpage ? 5 mn, et 5 x 2mn de partage

Comment faire 4

Faites la liste des questions que vous vous posez, la liste de ce que vous ne savez pas comment faire ou placer par rapport au reste

Comment faire (boucle à raffiner)

  1. Faites la liste des éléments matériel du projet
    1. ordinateur(s)
    2. téléphone ou tablette ➡ module Android
    3. capteurs ➡ module capteurs
    4. kinect ou leap ➡ module Kinect ou Leap
  2. S’il y a plusieurs appareils qui communiquent ➡ communication Client-Serveur
  3. Faites la liste des liens entre les matériels, la liste des échanges
  4. Faites la liste des éléments logiciels que vous avez identifié
    1. Identifiez l’appareil qui vous parait celui qui executera le logiciel (ça pourra changer) et créer une sous-boite dans la boite de l’appareil pour l’élément logiciel
    2. Mettez des liens entre les sous-boites pour tous les échanges
  5. Faites la liste des questions que vous vous posez, la liste de ce que vous ne savez pas comment faire ou placer par rapport au reste

Itérez pour réduire ce que vous ne savez pas

Les échanges

  • Essayez d’imaginer tous les échanges.
  • Entre chaque paire de blocs, posez vous la question si des données sont échangées (directement) ou pas.
  • Si des données sont échangées, faites en la liste et essayez de les évaluer en termes de nature et de volume et de fréquence.

Et si ?

  • L’expert vous dit que c’est trop gros pour un module: coupez en deux modules.
  • L’expert vous dit que c’est trop petit pour un module: regroupez l’activité avec un autre module.
  • Vous êtes bloqué sur une tâche que vous ne savez pas traduire en module: prenez conseil!
  • Vous trouvez un module proche mais avec une différence fondamentale: voyez avec l’expert s’il peut vous prendre quand même ou s’il vous envoie vers quelqu’un d’autre.
  • Vous ne trouvez pas le module dans la liste, et vos experts sont d’accord que c’est nécessaire: nous trouverons quelqu’un comme “expert”

Suggestions

  • Faites des schémas sur papier en plusieurs versions, voyez lequel est le plus lisible
  • Privilégiez le schéma qui parle à tout le monde, plutôt que celui qui vous plait le plus
  • Ne passez pas trop de temps sur chaque brouillon
  • Soyez prêt.e.s à jeter pour recommencer
  • S’il y a trop de choses pour un seul schéma, faites deux schémas (ou plus)
    • un schéma général et un autre schéma décrivant en détail la boite la plus complexe
    • deux schémas au même niveau pour les deux moitiés du projet
  • Montrez vos schémas en cours de construction à vos experts et recueillez des retours
  • Echangez vos schémas avec vos collègues d’un autre groupe pour recueillir des retours sur la lisibilité.

A faire pour la semaine prochaine

  • Faire votre découpage architectural, à rendre en version electronique
  • Je vous ferai des retours
  • Puis vous ferez une version 2 de votre découpage avec ce que vous aurez appris, à mettre dans votre rapport

Attentes PAN1

  • Dans le document “Cahier des charges” avec le scénario:
    • Schéma d’architecture
    • Description textuelle des blocs
    • Découpage en modules
  • Démontrez l’utilisation de Git
    • Existence d’un dépot pour le groupe
    • Un commit au moins par élève
      • Créez un fichier README.txt dans lequel chacun commit son nom sur une ligne différente

Attentes PAN1 Git

  • Créez une structure de dossiers standard:
    • Un dossier par programme séparé (client, serveur, android, programme en C…)
    • Pour un programme en Java pour PC, utilisez la structure:
      • src/org/pact/pactXY/moduleZ pour chacun de vos modules
      • test/ pour les fichiers de test
      • (bin/ qui est dans .gitignore)
      • .classpath (ou l’équivalent IntelliJ)
      • .project
    • Pour un programme Android, utilisez la structure générée par Android Studio
      • S’il y a des sous-modules, les mettre dans app/src/main/java/org/pactXY…