Analyse fonctionnelle
Plan
- L’analyse fonctionnelle
- Définition
- Diagrammes UML
- L’architecture logicielle
- Définition
- Séparation des responsabilités
Phases d’un projet
- Analyse des besoins
- Planification
- Conception
- Développements
- Recette
- Déploiement
- Maintenance
Dans les projets classiques (Cycle en V), ces phases étaient très ségmentées
- Important de discuter
- Reformulez
- Utilisez des mots simples
- Imaginez que vous expliquez le projet à vos grands parents
- parler doc, arrivée sur poste, initiatives
C’est quoi l’analyse fonctionnelle ?
- Première étape de tous les projets
- Détermine les fonctions, acteurs du produit pour répondre aux besoins du client
- Diagrammes pour échanger avec le client
- Priorise les travaux
- Permet de s’approprier le sujet
- Ce n’est pas du temps perdu car rajouter des fonctionnalités non prévues est extrêmement compliqué
- Cette phase sera la première partie du rapport intermédiaire
Les questions à se poser
- Quels sont les types d’utilisateurs qui vont utiliser mon application (administrateur, gestionnaire, client…) ?
- Quelles sont les fonctionnalités ? Fonctionnalités communes entre les profils ?
- Comment fonctionnent les processus de l’application ?
- Quels sont les diagrammes à utiliser ?
- Pour les premières questions diagramme de cas d’utilisation
- Processus -> diagramme d’activité
- Pourquoi faire des diagrammes ? D’un coup d’oeil on a toutes les infos
- Commentez vos diagrammes
Les diagrammes UML
- Cours de 1A
- UML 2.5, Pascal Roques, Eyrolles, Mémento (bibliothèque Ensai)
- Pas le temps de vous refaire un cours
- Il y a des ressources à la bibliothèque et sur internet
- Demandez à votre tuteur ce qu’il attend
Architecture logicielle
C’est quoi l’architecture logicielle ?
- Le pendant technique de l’analyse fonctionnelle
- Maintenant que l’on a le qui et quoi, on détermine le comment
- On dessine le code de notre application
- Vision macro de notre application (agencement des grandes pièces)
Pour le moment on ne fait pas encore de code.
On va seulement faire une ébauche de notre application avec les composants qui la compose (aussi bien logique que physique).
Par exemple dans votre cas vous allez sûrement avoir :
- Un code python qui tourne sur votre ordinateur
- Un webservice externe qui vous fournis des données
- Une base de données postgres.
C’est déjà 3 composants, mais rapidement on en beaucoup et il faut savoir comment les agencer
Pourquoi c’est important : parallèle avec l’architecture
- Pièces, l’installation électrique, l’eau, le gaz, contraintes législatives, s’adapter au terrain…
- Besoin de réfléchir comment il faut agencer tout ça dès le début
- Si on construit au fil de l’eau, on risque d’avoir une maison incohérente (au mieux)
- Ce n’est pas du temps perdu !
Certaines personnes disent même qu’on devrait passer plus de temps à analyser qu’à coder. Sujet à débat, mais cela montre bien que la phase d’analyse (comment je code les fonctions) est super importante !
ChatGPT peut presque coder à notre place.
Un grand principe : separation of concerns
Version macro en 3 couches.
- Présentation : tout ce qui se charge de l’affichage
- Business : c’est le métier de votre application, sa plus-value
- Data : stockage des données
Chaque couche communique avec celles adjacentes.
Une couche a juste à savoir comment elle doit demander une information et ce qu’on lui retourne.
Pas évident mais très important !!!
Les principales couches d’une application
- Présentation : tout ce qui se charge de l’affichage (page web, console, fenêtre)
- Métier : c’est le métier de votre application, sa plus-value
- Persistance : gère la persistance des données. Base de données ou système de fichiers
Pour votre projet
- Présentation : terminal
- Métier : votre code Python
- Persistance : base de données
Exemple page web
Zoom sur la couche métier
À l’intérieur de la couche Métier, il y a plusieurs sous-couches.
Dans les TP :
- Couche présentation : View (on navigue entre des vues)
- DAO, business_object, service
- Contrôleur (client) : Il reçoit les demandes de l’utilisateur via l’interface utilisateur (par exemple, une requête HTTP dans le cas d’une application Web) et appelle les services appropriés pour exécuter les actions demandées.
Les couches de la couche métier 1/2
- DAO (Data access object) :
- C’est la partie de votre code qui communique avec la base de données (CM4/TP4)
- Service :
- Code métier
- Manipule des objets métiers pour créer de l’information ou de la valeur
- Demande des objets à la couche DAO (TP4)
- Appelle les webservices externes (TP3)
Les couches de la couche métier 2/2
- Objets métiers :
- Couche transversale
- Représentent des concepts métiers que votre code va manipuler
- Objets avec surtout des attributs et peu de méthodes
- Contrôleur :
- Récupère les inputs des utilisateurs
- Renvoie les données à afficher
On découpe les objets :
- Attributs -> Objets métiers (~DTO)
- Méthodes -> Services
Pourquoi séparer en couches ?
- Travail en groupe 🦸♀️🧙♂️👨💼👩🔬
- Lisibilité du code 📖
- Débogages 🐞
Limiter les risques d’erreurs quand on modifie le code (éviter l’assiette de spaghetti) 🍝
Il faut savoir qu’un code doit être lisible par les autres.
Et les autres, ça peut être soi-même dans 2 mois. Blague sur la relecture de code.
Si on a un code bien séparé, différentes équipes peuvent travailler en parallèle.
Et séparer en couches permet de trouver rapidement la source du problème.
Informations à retenir
- Passer du temps à réfléchir aux différents modules d’une application n’est pas une perte de temps 🕵️♀️
- Diviser en couches permet de travailler en parallèle 🧪🧫📚
- Mais il faut encore réfléchir à comment bien coder 🤖
Possible en projet de se répartir les couches.