Vous êtes ici : FIL > Portail > Master Info > M1S1 > GL


GL - Génie Logiciel

Responsable

Les intervenants

Volume horaire

Chaque semaine :
Cours (1h30)
TD (1h30) + TP (2h) + travail personnel
TD lecture obligatoire (1h30)

Credits

5 ECTS 
Cedric Dumoulin
dernière modification : 14/06/2019 à 11:58:56


Objectifs

Ce cours a pour objectif de concevoir des applications orientés objets de façon systématique et reproductible. Dans ce cours, l'étudiant(e) apprendra à rechercher et établir les fonctionnalités d'une application, et à les modéliser sous forme de cas d'utilisation (C.U.) et de scénarios. IL ou elle apprendra à rechercher les classes et les acteurs nécessaires à la conception de l'application. L'étudiant(e) apprendra aussi des bonnes pratiques de conception, comme l'utilisation de patron de conception (design pattern), le découpage en couches de l'architecture , la structuration en paquetages et le maquettage.
Voir aussi le syllabus : syllabus

Contenu

Voir le syllabus : syllabus

Bibliographie

Voir le syllabus : syllabus 
Cedric Dumoulin
dernière modification : 16/09/2019 à 10:00:24

Gpe Nature Horaire Salle Enseignant e-mail
Cours Lundi 13h30-15h C. Dumoulin
1 TD mardi 08h30- 10h00 Michaël Launay
1 TP mardi 10h15 - 12h15 Michaël Launay
2 TD lundi 10h15-11h45 Cedric Dumoulin
2 TP lundi 15h15-17h15 Cedric Dumoulin
3 TD mercredi 13h30- 15h00 Xavier Le Pallec
3 TP mercredi 15h20 - 17h50 Xavier Le Pallec
4 TD mercredi 8h30- 10h Vincent Aranega
4 TP mercredi 10h15 - 12h15 Vincent Aranega
5 TD mardi 8h30- 10h Xavier Le Pallec
5 TP mardi 10h15 - 12h15 Xavier Le Pallec

Cedric Dumoulin
dernière modification : 14/06/2019 à 11:58:56

Semainier GL 2019

Début des Cours

  • Le lundi 16 septembre

Début des TD et TP

  • Groupe 3 et 5 (X. Le Pallec)
  • Semaine du 9 septembre
  • Groupe 1, 2 et 4
  • Semaine du 16 septembre

Planning

Le planning est susceptible de changer au cours du semestre.

vue du calendrier

vue du calendrier

Séances

Seance semaine tp td
S 1 TD1 : Constitution des équipes - Ecriture des scénarios concrets
S 2 TD2 : Recherche CU, classes et acteurs (TinCar)
S 3 TD3 : CUs : relation extends et include
S 4 rendu TD4 : Diagramme de classes (TinCar)
------ :-------: ---------- ------------------------------------------------------
S 5 correction TD5 : Description textuelle de CUs
S Abs.
S 6 TD6 : Diagramme de séquences
int p. -- Interruption pedagogique
S 7 4/11 rendu TD7 : Pattern MVC (diagramme de classe complet + dss) + Hierarchisation
------ :-------: ---------- ------------------------------------------------------
S 8 11/11 correction TD8 : Diagramme classe ++ (enumeration)
S 9 18/11 TD9 : Recherche écran, maquettage
S 10 25/11 TD10 : Design Pattern
S 11 2/12
S 12 9/12 Rendu en fin de semaine
------ :-------: ---------- ------------------------------------------------------
s 13 16/12 Soutenances Soutenances
------ :-------: ---------- ------------------------------------------------------

Contenu des séances

Semaine 1

  • TD 1 : User stories (scénarios concrets)
    • Présentation des sujets
    • constitution des équipes (4 à 5 personnes max)
    • choix d'un sujet par chaque équipes
    • Ecriture des premier scénarios concrets par les équipes
    • Un scénario concret raconte comment plusieurs personnes utilisent le futur logiciel. Il peut décrire les écrans du logiciel et les interactions des personnes avec le logiciel.
    • un scénario concret ne décrit pas le fonctionnement interne de l'application (pas de technologies).
    • Le logiciel est décrit par plusieurs scénario concrets.
    • les scénario concrets doivent être complémentaires : ils doivent décrire différentes utilisations du logiciel.
    • Un scénario concret doit avoir plusieurs personnages (acteurs).
  • TP 1 :
    • Ecriture collaborative des scénarios concrets.
    • Utilisation des outils collaboratifs : git, markdown,
    • outils possible :
      • langage : markdown
      • editeur : atom
      • git

Semaine 2

  • TD 2 : recherche des CUs, classes et acteurs
    • recherche des CUs, classes et acteurs (TinCar)
    • (ancien TD1)
    • Glossaire métier
  • TP 2 :
    • Papyrus
    • prise en main
    • Construire les premiers diagrammes de CUs, classes et acteurs avec Papyrus

Semaine 3

  • TD 3 : relation extends et include
    • relation extends et include sur les CU trouvé lors du TD 2
  • TP
    • travaille sur le projet ## Semaine 4
  • TD 4 : Diagramme de classe
    • Diagramme de classe (TinCar)
    • diagrammes
    • paquetages
  • TP
    • travaille sur le projet

Semaine 5

  • TD 5 : Description textuelle des scénarios
    • Description textuelle des scénarios
    • Hierarchie des CUs
  • TP
    • travaille sur le projet
    
    Cedric Dumoulin
    dernière modification : 16/09/2019 à 09:52:02

Sujets GL 2019-2020

Exigences communes à tout les Sujets

  • L'application utilise un ORM. Les classes ne doivent pas contenir d'artefacts liés aux bases de données.

Sujet 1 - Prises de commandes dans un restaurant

Un restaurant veut informatiser la gestion des prises de commandes. L'application doit permettre aux serveurs de prendre les commandes des clients et de suivre l'avancement, aux cuisiniers et au chef de cuisine de recevoir et traiter les commandes, aux barman et au glacier de recevoir et traiter la partie de la commande les concernant. L'application doit aussi permettre de calculer l'addition et de la regler. Le serveur prend une commande sur une tablette en choississant les plats et/ou les menus dans une liste existante. L'application doit permettre aux personnes concernées (le patron ?) d'établir cette liste de plats. Seuls les serveurs peuvent modifier les commandes. Les cuisiniers et les préparateurs ne peuvent pas les modifier. Par contre, ils peuvent indiquer qu'un plat n'est plus disponible (si un ingrédient n'est plus en stock par exemple). On doit aussi pouvoir suivre l'évolution de la commande et retrouver qui a préparer quoi sur la commande. Optionellement, l'application permet aux clients eux-mêmes de prendre la commande à partir d'une tablette.

Sujet 2 - Informatisation d'une Compagnie aérienne

Vous êtes chargés de réaliser une application de réservation de billet d'avions. L'application permet :

  • à la compagnie de créer et modifier des vols, avec une date, un lieu de départ et un lieu d'arrivé, un avion.
  • à la compagnie de gérer la liste des avions qu'elle détient (type d'avion, capacité)
  • à un voyageur de créer un compte dans l'application, de consulter les vols disponibles, et de réserver ou modifier un vol.

Sujet 3 - Informatisation de la gestion de spectacles

Une société gérants des évènements du type concerts, spectacles, meeting aériens… veut informatiser ses activités. Cette société met en relation des organisateurs d'événements, des propriétaires de lieux où organiser des événements et les spectateurs. L'application devra permettre, entre autre :

  • à un propriétaire de lieux où organiser un événement de s'inscrire dans l'application, de mettre à disposition un ou plusieurs lieux, de décrire les lieux (capacité d'accueil, informations sur le lieux…), de déterminer les dates de disponibilités, de consulter les locations…
  • à un organisateur d'événement de chercher un lieu disponible, de créer un événement, de fixer des prix pour les tickets, de donner des renseignements sur l'événement, de consulter la vente des tickets…De plus, le jour de l'événement, l'application permettra de contrôler les billets soit par scan, soit par saisie du numéro. Il faut bien entendu gérer les cas de fraudes, comme par exemple un ticket imprimé plusieurs fois, ou les faux tickets.
  • à un spectateur de choisir un événement, de s'enregistrer sur l'application, d'acheter un ticket, d'imprimer son ticket ou de le stocker sur son téléphone, de gérer ses tickets.
  • à la société gérant les événements de facturer ses services, de consulter les comptes des clients…

Les fonctionnalités de l'application sont à affiner et à détailler (scénarios et cas d'utilisations)

À propos de la facturation

Il faut réfléchir au modèle de facturation.

  • Pour un propriétaire de lieu, cela peut être soit un pourcentage sur le prix demandé pour la location, soit un abonnement d'un an avec un tarif fixé. Quand l'abonnement prend fin, le lieux n'est plus disponible.
  • Pour un organisateur, cela peut être un prix fixe pour chaque spectacle en fonction du nombre de spectateurs attendus.
  • Pour un spectateur, cela peut être un prix fixe par ticket.

Sujet 4 - Poids du cartable

Dans les classes de primaire, collège et lycée, les élèves doivent transporter leurs fournitures scolaires dans leur cartable ou leur sac. Les parents d’élèves constatent que le poids du cartable journalier est bien trop lourd pour ces élèves : en moyenne 8,5 kg par élève [1] ! Idéalement, le poids d’un cartable ne devrait pas dépasser 10% du poids de l’élève. Le poids d’un cartable est constitué du cartable lui-même, des cahiers et fournitures, des manuels, des affaires de sport... Mais pourquoi le cartable est-il si lourd ? A cela plusieurs raisons qui peuvent se cumuler :

  • Les élèves, surtout dans les « petites classes », ne savent pas ce qu’ils doivent prendre, alors ils prennent toutes leurs affaires.
  • La consigne de ce qui doit être apporté lors du cours est soit mal expliquée, soit mal comprise, parfois non dite
  • Certains enseignants demandent des cahiers ou des manuels trop lourds (cahier 24x36, 196p).
  • Certains cours nécessitent plusieurs manuels et cahiers. Les éléves ne savent pas toujours exactement ce qu’ils doivent prendre.
  • Les enseignants ne se rendent pas forcément compte du poids total de ce qui est demandé pour toutes les matières. Ils n’ont pas une vue globale de ce qui est demandé pour un jour donné (par exemple les jours avec beaucoup de cours).
  • ...

Cette application vise a donner un aperçu du poids théorique du cartable demandé aux élèves. Les enseignants pourront voir pour chaque classe et chaque jour le poids du cartable demandé à un élève. Ce poids est calculé en fonction du poids d’un contenant de référence (cartable ou sac), et du poids des cahiers et manuels demandés aux élèves par les différents enseignants pour ce jour-là.

L’application permet aux enseignants de renseigner les cahiers et les manuels qu’ils demandent pour chaque cours. L’application facilite la saisie des informations en autorisant les répétitions (hebdomadaires, semestrielles...). Les enseignants peuvent vérifier le poids du cartable, ainsi que l’influence sur ce poids des fournitures et manuels qu’ils demandent. L’application permet aux élèves de connaitre le poids de leur cartable, en fonction de ce qu’ils prennent réellement. Les élèves peuvent aussi consulter ce qui est réellement demandé par un enseignant pour un cours donné, ce qui permet de limiter le nombre d’affaires à transporter.

Les parents d’élèves, les élèves, les enseignants et le personnel administratif peuvent consulter les poids moyens journaliers pour les classes de leurs établissement. L’application permet de renseigner le poids de chaque fourniture et manuel. Elle propose une liste de fournitures standard, ainsi que leurs poids, mais chaque enseignant, élève, ou établissement peut ajouter de nouvelles fournitures et spécifier leurs poids. Il est aussi possible de modifier un poids de manière individuel pour une fourniture existante : ainsi un élève peut spécifier le poids réel de son cartable ou d’un de ses cahiers afin de connaitre le poids de « son » cartable. L’application doit être facile à utiliser, aussi bien pour les enseignants que pour les élèves. L’application est paramétrable au niveau d’un établissement (spécification des emplois du temps, des fournitures par enseignants...).

[1] [http://www.fcpe.asso.fr/index.php/nos-campagnes-4/le-poids-du-cartable](http://www.fcpe.asso.fr/index.php/nos-campagnes-4/le-poids-du-cartable)

[2] [http://www.lepoint.fr/sante/kine/mal-de-dos-le-scandale-du-poids-des-cartables-14-09-2015-1964468_2467.php](http://www.fcpe.asso.fr/index.php/nos-campagnes-4/le-poids-du-cartable)

[3] [http://www.education.gouv.fr/cid5704/poids-du-cartable.html](http://www.education.gouv.fr/cid5704/poids-du-cartable.html)


Cedric Dumoulin
dernière modification : 26/11/2018 à 16:24:34

Rendus de GL

Dates des rendus 2019-2020

La date de rendu est la suivante, sauf spécification contraire de votre intervenant.

Rendu Dates
Rendu 1 vendredi 11/10 20h
Rendu 2 vendredi 15/11 20h
Rendu 3 vendredi 13/12 20h
Soutenances semaine du 16/12

Contenu des rendus

Pour le projet de GL, On vous demande de rendre un document à des dates précises.

Il y a 3 rendus. Les rendus 2 et 3 sont la suite du rendu précédent.

Les documents sont à rendre impérativement sur l’intranet du FIL avant les dates et heures précisées suivant des modalités qui vous seront indiquées en TD (interface PROF).

Patrons pour le document de rendu

Premier rendu

  • Plusieurs scénarios concrets (au moins un par membre de l’équipe).
    • Il faut choisir des scenarios représentatifs de l’utilisation de l’application.
    • un scénario peut être décrit sous forme textuelle (histoire), bande dessinée, vidéo …
    • Il faut se focaliser sur l’interaction avec l’application.
  • Tous les cas d’utilisation (CU)
    • Issues des scenarios ou non
    • Un scénario doit produire plusieurs CUs
    • Des CUS peuvent être communs à plusieurs scénarios
    • Pour chaque CU :
      • un nom parlant (Verbe-complémant)
        • description courte (1 à 2 lignes) du CU
        • indiquer dans quels scenarios il apparait (traçabilité)
      • il doit être dans au moins un diagrammes de CU
      • regrouper les CUs par affinités si possible
      • Diagrammes de CUS
        • Un diagrammes montrants les CUs principaux
        • Plusieurs diagrammes détaillant les CUs
  • Liste des acteurs
    • factorisation des acteurs (si possible)
  • Toutes les classes du domaine
    • Il faut identifier les premières classe du domaine de l’application
    • Uniquement des classes du domaine (pas de classes techniques
    • Faire apparaitre les premières
    • Faire apparaitre les attributs correspondants au domaine (pas d’attributs techniques
    • Regroupement des classes en paquetage (premier essai)
    • Diagrammes de classes du domaine
      • Un diagramme montrant les principaux paquetages et/ou Classes
      • Plusieurs diagrammes détaillant les Classes
  • Glossaire métier
    • Définition des termes métier utilisés dans les CUs

Deuxième rendu

Le deuxième rendu consiste à enrichir le premier rendu. C’est le même document, avec plus de contenu. C’est une nouvelle itération du document.

  • Ajouts de nouveaux scénarios (au moins un par membre de l’équipe).
    • CUs correspondants
    • Classes correspondantes
    • Nouveaux paquetage
  • Description de l’architecture logicielle
    • Quelle est l’architecture qui sera utilisée pour l’application (en couche, client/serveur …)
      • Faire apparaitre (dans un diagramme de classes) les principaux paquetages participants à l’architecture logicielle.
  • Hiérarchie des CUs
    • Classement des CUs en fonction des risques
    • La liste des CUs retenus
  • Scénarios abstraits
    • Description textuelle des scénario abstraits
      • Chaque CU doit être décrit par son scénario abstrait correspondant.
      • Une description par membre de l’équipe
      • Ne pas décrire le CU ‘authentification’
    • Diagramme de Séquence Système (DSS) pour chaque CU
    • Diagramme de séquence détaillé pour chaque DSS
  • Description des premiers écrans de l’application
    • description par l’exemple (snapshot, maquette …)
    • Cela peut être un raffinement des écrans déjà proposés dans les scénarios concrets.
      • Il ne faut pas hésiter à remettre en cause les écrans proposés dans les scénarios concrets
  • Glossaire de l’ingénierie des besoins
    • Explication des termes utilisés dans la description de la solution proposé :
      • explication des classes, paquetages, CU …

Troisième rendu

Le troisième rendu consiste à enrichir le précèdent rendu. C’est le même document, avec plus de contenu. C’est une nouvelle itération du document.

  • Le contenu du rendu 2 plus ce qui suit
  • CUs supplémentaires, Description textuelle, Diagramme de Sequence Système et Détaillé pour les nouveaux CU
  • Raffinement final des diagrammes de Classes
  • raffinement des paquetages
  • Maquette interactive (coté client)

Documents à produire

Vous devez produire deux documents: - un document de suivi de projet (voir paragraphe concerné) - un document d’analyse et de conception

Document de suivi de projet

Pour suivre votre projet, vous devez maintenir un document de suivi de projet. Ce document est partagé entre tous les membres du groupe en lecture et écriture. Le partage ce fait dans GIT.

Chaque semaine: - vous définissez les tâches à faire, et vous les indiquez dans le document (nom, résumé, temps estimé, affectation, remarques) - vous répartissez les tâches entre les membre du groupe - vous faites le points sur les tâches qui étaient à faire (finis, temps effectif, …)

Ce document sert à planifier votre travail, à répartir le travail, et aussi à vérifier le bon fonctionnement du groupe. Il permet à votre enseignant de détecter des disfonctionnements au sein d’un groupe. Mais si vous constatez vous même des dysfonctionnements, il vous est conseillé de les rapporter le plus vite possible à votre intervenant. (Par exemple: absence répété d’un membre, travail non fait, …)

Document d’analyse et de conception

C’est le document principal de votre projet. Il doit suivre le template proposé dans le livre support du cours.

Dans votre documents on doit trouver: - Le nom de tous les membres du groupe. - La date de rédaction et le nom du (es) rédacteur(s) - Les pages sont numérotées. - Si un document doit être rendu plusieurs fois parce qu’il a évolué, il doit posséder un numéro de version et un historique. - Vous devez suivre le template proposé dans le livre.

Travail collaboratif

Votre projet est un travail collaboratif entre les membres de votre équipe.

De plus, il doit être possible de suivre l’évolution de votre projet, et de savoir qui a écrit quoi dans les documents. Pour cela, il faut utiliser GIT, et des documents de type texte. Afin de permettre la mise en page de votre document, vous devez utiliser un langage d’édition comme markdown, et un éditeur adéquat comme atom.

Vous devez utiliser des outils facilitant la collaboration : - git - pour partager les documents - vous pouvez créer un compte git au FIL (voir les pages du FIL) - fichier texte pour le document d’analyse - atom comme éditeur - markdown comme langage d’édition.

Vous ne pouvez pas utiliser google doc car celui-ci ne permet pas le suivi de projet.

Contenu de la maquette

  • Sauf indication contraire, la maquette doit contenir tout les écrans de l’application, y compris les écrans d’erreurs et de validation. Cela reste une maquette: l’application n’est pas opérationnelle. L’enchainement des pages est factice (lien hypertexte, pas de vérification de données ni de calcul).
Page en cours de construction


Evaluation

L'évaluation s'effectue suivant une procédure de contrôle continu. Il y a 3 rapports a rendre dont un finale.
Il n'y a pas d'examen final, la soutenance finale tient lieu d'examen.
Il y a un examen de rattrapage.

Un sujet de projet est donné en début de semestre. Le projet consiste a analyser et concevoir une application d'après le sujet. Chaque rapport correspond à une itération de cette analyse et conception.

L'unité acquise apporte 5 ECTS.


Cedric Dumoulin
dernière modification : 14/06/2019 à 11:58:56

Documents GL



Cedric Dumoulin
dernière modification : 20/09/2019 à 15:44:27