PACT Génie Logiciel 2

Equipe encadrement informatique

Programme

  • Diagrammes:
    • Sequence
    • Activité
  • Interfaces:
  • Organisation du travail:
    • Dossiers
    • Git
    • module Tests et Intégration
  • GIT:
    • rappels INF103
    • branches et divers
  • Ateliers:
    • Retour sur les diagrammes d’architecture (évolutions, demande du jury)
    • Travail sur les interfaces

Diagrammes: Autres types

Selon vos besoins, vous pouvez avoir besoin d’un autre type de diagramme:

  • diagramme de séquence
  • diagramme d’activité

Ces diagrammes ne sont pas obligatoires pour tous les groupes mais je pourrais être amené à en demander un pour certains groupes. Et vous pouvez choisir d’en ajouter un si vous en sentez le besoin dans le groupe.

Diagrammes: séquence

Diagrammes: Utilité d’un diagramme de séquence

  • client-serveur avec un protocole complexe
  • client-serveur avec plus que deux acteurs

Diagrammes: activité

Diagrammes: Utilité d’un diagramme d’activité

  • clarifier un fonctionnement complexe
  • se mettre d’accord à plusieurs sur les détails d’un fonctionnement, par exemple entre deux modules
  • identifier les zones d’ombre: en faisant le dessin, on se rend compte ce qui est bien maitrisé ou pas

Interfaces

  • Objectif:
    • Définir plus précisément les interfaces dans votre architecture
    • Permettre de faire évoluer un bloc de l’architecture indépendamment des autres

Interfaces: Rappel

  • Un objet appelle une méthode d’un autre objet
    • Envoi d’un message

Interfaces: Types d’interface

  • Trois situations en fonction de Objet 1 et Objet 2
    • Objet 1 et Objet 2 dans le même module:
      • aucune contrainte, mais veillez à appliquer les bons principes de INF103 (encapsulation, délégation, non-intrusion)
    • Objet 1 et Objet 2 dans deux modules différents:
      • Se mettre d’accord entre les deux modules
      • Utiliser l’encapsulation, les interfaces Java ou classes abstraites pour définir l’échange
    • Objet 1 ou Objet 2 est dans une bibliothèque
      • Vérifier les APIs dans la documentation de la bibliothèque
    • Objet 1 et Objet 2 sont dans deux programmes différents ou deux machines différentes
      • Utilisation de fichiers d’échanges, de pipes, de base de données …
      • Utilisation de Socket et protocole de communication

Interfaces: Comment concevoir une interface?

  • Moyens
    • Définir des méthodes et les données manipulées par ces méthodes (String, float, Objects)
    • Ne donner accès qu’aux méthodes indispensables pour l’appelant
    • Faire évoluer l’interface de façon compatible
  • Méthode
    • Créer dès le début un modèle de données qui va servir d’entrée de test au module aval
    • Dès que le module amont produit une donnée, comparer au modèle
    • Ajouter la production réelle du module amont aux tests du module aval

Interfaces: Interface de communication

  • Contrat permettant la communication entre
    • Logiciels sur une même machine ou sur des machines distantes (e.g. client/server, P2P)
    • Matériels informatiques et logiciels
  • Type de communications
    • Notifications, Signaux
    • Échange de données
  • Protocole de communication
  • Format de données

Interfaces: Communication inter-programmes

  • Communication par fichiers
    • Quel format de données?
    • Quel débit de données à écrire/lire?
    • Attention
      • accès concurrentiel si écriture et lecture en même temps

Interfaces: Communication inter-programmes

  • Communication par « socket »
    • Quel protocole (IP? TCP? UDP?)?
    • Quel format de données?
    • Synchrone / Asynchrone?
    • Push / Pull

Interfaces: Format de données

  • Binaire à proscrire (difficile à débugger) sauf si
    • Les données sont fournies par un capteur,
    • Les données sont volumineuses
  • Utiliser du texte
    • Attention au codage de caractères (accents, langues étrangères …)
    • Structuration des données
      • Ligne à ligne, séparé par des virgules/tabulations (CSV)
      • Plus structuré
        • XML
        • JSON

Organisation du travail

  • Vous allez devoir travailler tous dans le même dépot Git.
  • Selon les phases de travail, adoptez des façons de travailler adaptées:
    • Un dossier (ou +) par module
    • Une branche officielle par module, et vous pouvez avoir des branches privées par personne ou par ‘sous-module’
    • le binôme Test et Intégration propose l’organisation générale
    • git mv permet de déplacer des fichiers ou dossiers suivis par Git en gardant leur historique

Organisation: Git

  • Vous devez avoir un dépot unique pour votre groupe, gitlab.telecom-paris.fr
  • Pour utiliser gitlab.telecom-paris.fr
    • Votre dépot existe https://gitlab.telecom-paris.fr/pact/2019-2020/pactXY.git ou git@gitlab.enst.fr:pact/2019-2020/pactXY.git
  • Utilisez SmartGit ou la ligne de commande: voir les TP INF103

Organisation: Dossiers

Source

  • Par langage, un dossier source général (sauf un langage utilisé pour un seul module comme matlab)
  • Par module, un sous-dossier source

Cette organisation permet aux intégrateurs de faire des références simplement, tout en ayant des merges triviaux entre deux modules différents.

Autres

  • Faites des dossiers pour les autres informations par module
    • Bibliothèques
    • Fichiers de données
    • Rapports et autres archives de votre travail

Organisation: Android

Android Studio impose une structure de fichiers complexe, qu’il vaut mieux respecter. Le dossier source général est celui de Android Studio. Organisez les sous-dossiers par module si besoin (un seul module dans un package donné)

  • app
    • manifests
    • java (dossier source)
    • generated Java (pas touche)
    • res (xml, icones, layouts, menus…)
  • Gradle Scripts

Si vous partagez du code entre PC et Android, alors construisez la même structure de packages des deux cotés, et faites un lien symbolique ou un git submodule.

Un lien symbolique est une façon de faire apparaitre le même dossier à deux endroits dans le système de fichier. Un git submodule est un lien symbolique spécifique à git.

Organisation: Eclipse

Notez qu’un projet Eclipse peut être dans n’importe quel dossier, pas seulement dans le dossier “workspace”.

Organisation: Tests et Intégration

Travail à faire:

  • intégration
    • prévoir/gérer dès maintenant l’organisation du dépot git et des dossiers
    • écrire l’architecture logicielle du projet = la liste des logiciels développés dans le projet et leurs interactions, cela inclut les logiciels de préparation, de test
    • option: intégration continue
  • tests (à voir en séance GL3)
    • plan de test de chaque module, à faire par le binome du module, le binome T&I ne fait que collecter
    • plan de test global, à faire par T&I sur la base des plans de test des modules

Organisation: Estimer le travail

  • le test dépend de la complexité du projet, du nombre de possibilités différentes à tester pour être sûr que tout marche (évaluation après GL3)
  • l’intégration dépend du nombre d’interfaces communes entre deux modules dans un logiciel (un appareil et un langage) et du nombre de logiciels

Organisation: Logiciels de préparation

  • logiciel pour mettre des images dans un bon format, pour les prétraiter
  • logiciel de crawling = recherche d’informations sur Internet pour les stocker dans une base de données avant utilisation
  • la partie apprentissage du machine learning, qui ne tourne pas dans le produit final mais ne fait que préparer le modèle.
  • logiciel de création ou d’import de modèle 3D

Organisation: Intégration continue

Le principe de l’intégration continue est de faire des cycles de développement court, et d’utiliser le test automatique. Nous vous recommandons de faire plusieurs cycles de développement avant le PAN3, plutôt que chaque module produit une v1 juste avant le PAN3.

Avantages:

  • répartir le travail d’intégration
  • réduire les risques d’incompréhension
  • donner plus de temps pour trouver et corriger les problèmes

Organisation: Exemple idéal

  • tous les modules produisent une v0 très simple, qui ne fait pas tout mais qui a les bonnes interfaces
  • les intégrateurs créent le cadre qui accueille les v0 et testent la cohérence
  • à chaque nouvelle version d’un module, les intégrateurs peuvent faire des vérifications de progrès et de non regression
  • les tests de non régression sont automatisés pour alléger la tâche des intégrateurs.

Organisation: A faire

  • une étude de faisabilité des cycles courts
    • ça fait partie du module Tests et Intégration
  • pertinence ou pas des cycles courts pour le projet/module
    • faisable pour beaucoup de modules
    • plus compliqué avec un module ‘matlab puis Java’
  • prévoir au moins une release intermédiaire avant PAN3

Organisation: Attention

  • Vous serez notés en fonction des logs git
  • Si vous n’utilisez pas git, ou si un autre committe pour vous, vous risquez d’avoir 0, sans possibilité de vous rattrapper
  • Ne laissez pas traîner des problèmes de connection à Git
  • Ne committez pas les sources d’une librairie externe ou du code que vous n’avez pas écrit vous même, importez plutôt un .jar (bibliothèque en version compilée)
  • Nous utilisons un inspecteur git qui donne ce genre de résultats où il est très clair de voir qui a contribué:

GIT: Rappel INF103

  • concept of working directory, stage and local repository (.git)
  • git init: create a local repository
  • git status: get info on the local repository
  • git log: get info on the commits
  • git add: start tracking a new file, or stage new changes for next commit
  • git commit: store a new set of changes to tracked files
  • git remote add: connect a remote repository to the local repository
  • git push: push the state of the local repository to a remote repository
  • git pull: pull the state of a remote repository to the local repository
  • git clone: clone a remote repository to a local folder
  • git checkout: change the version of the local copy
  • .gitignore: list of files to ignore

GIT: Level 2

  • git branch: manage multiple branches
    • local branches (add remove)
    • remote branches (add remove)
  • git stash: save local changes from the working directory into a temp container
    • git stash pop, git stash clear
  • git revert: cancel the changes from a commit (by creating an opposite commit)
  • git remove: untrack and delete files
  • git commit –amend: add to the previous (unpushed) commit
  • git checkout – file: cancel local modifications of file
  • git fetch: get state from remote repository without merging ( = pull with no merge)
  • git tag: associate a symbolic name to the current repository state
  • git reset: used to unstage modifications (opposite of git add)

GIT: Cheat sheet

Vous pouvez trouver une série de tutoriels videos pour se sortir des erreurs classiques

GIT: Branches

  • Vous avez déjà manipulé une branche: master.
  • Une branche n’est rien qu’une étiquette sur un commit.
  • Une branche peut être locale ou distante.
  • Supprimer une branche ne supprime pas les commits
  • Utilisez des noms de branches explicites, sans accents et sans espaces
  • Quand vous faites un commit, la branche courante avance sur le nouveau commit.

GIT: Revert

Vous avez fait une bétise et commit sur une branche une version qui ne devrait pas y être.

Vous voudriez supprimer un commit.

En GIT, vous pouvez faire un second commit qui inverse les changements du premier, et ça s’appelle git revert

git revert HEAD crée un commit inversant le commit courant (celui qui arrive à l’état courant)

GIT: Remove

Supprimer un fichier n’est pas la même chose que cesser de suivre (track) ce fichier dans GIT.

git rm file supprime le fichier ET cesse de le suivre (après commit)

git rm --cached file cesse de suivre le fichier dans git (après commit) sans le supprimer du dossier courant. Il apparaitra comme “untracked”, sauf s’il est mentionné dans .gitignore

GIT: Amend

Vous venez de faire commit, et vous vous rendez compte que vous avez oublié une ou deux modifications. Vous les faites, puis

git add modifs puis

git commit --amend pour ajouter les modifs au commit précédent.

Bien sûr, il ne faut pas faire celà si vous avez déjà fait un push. Si vous avez déjà fait un push, alors faites un autre commit. Il n’y a pas de commit trop petit.

GIT: Checkout –

Vous avez effacé un fichier Main.java par erreur, ou vous l’avez modifié malencontreusement.

git checkout -- Main.java (il y a un espace avant et après le –)

Et votre fichier Main.java est restoré à son état antérieur.

GIT: Fetch

Vous voulez voir ce qu’ont fait les autres, mais vous n’avez pas encore le courage de faire un gros merge. Alors plutôt que de faire git pull, faites git fetch pour faire l’équivalent du pull sans le merge.

GIT: Tag

Vous voudriez l’équivalent d’une branche mais qui ne suit pas les commits, une étiquette qui reste sur le commit où elle a été placée. Par exemple, vous voulez mettre l’étiquette: ‘versionPan3QuiMarche’

Ca s’appelle un tag: vous faites checkout de la version à tagger et

git tag versionPan3QuiMarche

GIT: Reset

Vous avez fait git add sur tous les fichiers modifiés, puis vous vous rappelez qu’un fichier Main.java n’est pas prêt pour le commit. Les autres modifications sont demandées en urgence.

git reset Main.java fait sortir Main.java du stage, donc fait l’inverse de git add. Main.java ne fait plus partie du prochain commit.

Utiles

  • git shortlog -s -n --all : nombre de commit par auteur
  • git log --all --decorate --oneline --graph : présente une version texte d’une vue des branches

Fast-forward

Un fast-forward est un merge trivial.

Pour un merge, il y a la version courante et la version à fusionner. Si la version à fusionner est sur une autre branche, la fusion n’est pas triviale.

Par contre, vous êtes sur master, vous venez de faire un git fetch et plusieurs nouveaux commits sont apparus sur master, origin/master est “devant” master. A ce moment, git merge origin/master est un fast-forward.

ff

Ateliers

Retour sur les découpages en blocs du PAN1

  • En groupe, vous regardez votre schéma et vous vous posez toutes les questions
  • Le jury a-t-il fait des demandes ? Il y a eu des questions de compréhension ?
  • L’encadrant passe dans les groupes et fait des suggestions
  • Votre connaissance du projet a évolué depuis le moment où vous avez fait le schéma: votre meilleure connaissance des modules suggère-t-elle des changements ?

Atelier Interfaces

  • A partir de la liste de vos modules/boîtes noires, faire la liste des connections entre boîtes
  • Pour chaque connection, produire autant d’information que possible
    • si l’interface est informatique, écrire la signature des fonctions
    • si l’interface est électronique, décrire le protocole de communication
    • dans les deux cas, décrire la nature de l’information qui circule, les débits, les fréquences, les précisions…