Génie Logiciel

Modèle linéaire

Cascade, Modèle en V

• Plus on avance dans les étapes plus un changement coûte cher.
• Permet une conception bien pensée.
• Adapté à des projets dont les exigences sont bien comprises et les ressources limitées.
• Avantages 👍
  • Simple et facile à suivre.
  • Axé sur la documentation et l'analyse
  • Permet une conception bien pensée
• Inconvénients 👎
  • Purement linéaire.
  • Trop rigide
  • Pas de feedback du client avant la livraison
  • Vérification tardive

Modèle itératif

Prototypage, Code-et-modifie (non recommandé pour projet à livrer)

• Pertinent pour les projets où les exigences ne sont pas clairement définies/comprises.
• Chaque version a pour but de se rapprocher du système cible plus que la version précédente.
• Architecte la coquille du produit complet, puis améliore chaque composant.
• Avantages 👍
  • Réutilisation de prototypes.
  • Produit visible très tôt
  • Souci de vérification et validation du client anticipé
  • Intégration facilitée, moins de raffinement
• Inconvénients 👎
  • Retravaille chaque itération.
  • Produit livré à la fin

Modèle incrémental

Phase

• Pertinent pour les projets d'envergures.
• Pour gérer de plus grandes information, utiliser le raffinement par étapes.
• Permet de développer par ordre de priorité (on se concentre ce qui est important à chaque étape).
• Chaque incrément abouti à une livraison.
• Avantages 👍
  • Développer par ordre de priorité.
  • Livraison de composants rapides
  • Facile de mesurer le progrès
• Inconvénients 👎
  • Pas de processus visible et clair à suivre.
  • Tache d'intégration prend plus d'importance

Modèle itératif & incrémental (I & I)

• Tous les flux d'activités (workflow) sont impliqués dans chaque incrément, mais certains vont dominer plus.
• Plusieurs opportunités de tester, recevoir du feedback et s'ajuster.
• Robustesse de l'architecture peut être déterminée tôt dans le développement.
• Livrables spécifiques pour chaque incrément et chaque workflow.
• On peut atténuer et résoudre les risques plus tôt.

Ingénierie des exigences

• Cueillette des besoins: Entrevue, Sondage, Observation
• Compréhension du domaine: Glossaire, Persona, Prototypage
• Analyse des besoins et risques
  • Besoins fonctionnels: Spécifie une action que le système doit accomplir sous forme d'interaction entre le système et son environnement.
  • Besoins non-fonctionnels: Spécifie des propriétés du logiciel même (utilisabilité, fiabilité, performance, sécurité, interopérabilité...)
  • Priorisation des besoins: Par valeur d'affaire ou par sévérité de risque.

Cas d'utilisation

• Capture le comportement d'un système tel qu'un utilisateur extérieur le voit. Regroupe les besoins fonctionnels en unités cohérentes (cas d'utilisation), ayant un sens pour les acteurs.
• Décrit une interaction entre le logiciel et ses utilisateurs (acteurs) qui initient les CUs.

Scénario

• Séquence spécifique d'interactions entre les acteurs et le système et d'actions subséquentes du système
• Acteurs: Principal (initie le CU) et secondaires (intervient dans la réalisation du CU).
• Scénario principal: Décrit ce qui se déroule normalement, quand il n'y a pas d'erreur.
• Scénario alternatif: Variantes du scénario principal. Exceptions que le système doit traiter.
• Préconditions nécessaires pour entamer le scénario principal.
• Postconditions de l'état du système lorsque le CU est complété avec succès.

Caractéristique de l'analyse

• Pas nécessairement compréhensible par le client.
• Force le client et les développeurs à prendre des décisions difficiles le plus tôt possible.
• Déterminer la partie à informatiser, les ressources physiques nécessaires, les exigences conceptuelles et matérielles.

Modèle d'analyse complet

• Modèle fonctionnel
  • Définir les fonctionnalités du système
  • Cas d'utilisations + scénarios
• Modèle dynamique
  • Définir le comportement du système
  • Activités + Flux de données
• Modèle d'objet
  • Concepts manipulés par le système et leurs propriétés
  • Classes, composants

Objectifs

• Forte cohésion: Éléments ne sont pas réunis dans un même module par hasard, ils forment un tout pour réaliser une tâche
• Faible couplage: Modules sont relativement indépendants : dépendent le moins possible des éléments d'autres modules
• Abstraction: Décomposition intuitive exprimée en termes du problème, qui permet de se concentrer sur un module à la fois
• Encapsulation et dissimulation d'information: Détails d'implémentation propices à changer sont cachés derrière une interface stable

Conception architecturale (haut niveau)

• Définit la structure et l'organisation générale du logiciel
• Décrit les modules clés du domaine, les relations entre eux et contraintes

Conception détaillée (bas niveau)

• Réalise chaque cas d'utilisation
• Respecte le plan de la conception architecturale
• Décrit le fonctionnement interne de chaque module
• Prépare l'implémentation

Décomposition du système

• Décomposer le système en petits modules qui sont individuellement plus faciles à concevoir et implémenter
• Décomposition fonctionnelle: Décomposer le système en modules par fonctionnalité
• Système est partitionné en modules distincts mis en relation
• Établir une hiéarchie: Facilite la compréhension de la structure par niveau d'abstraction

Interface: partie publique

• Quoi offrir? Analyse et conception
• Ensemble des ressources (opérations, attributs) rendues accessibles aux autres modules (clients)
• Conception d'un module ne nécessite que les interfaces des modules qu'il pourra utiliser

Implémentation: partie privée

• Comment le réaliser? Conception et implémentation
• Façon dont les ressources sont concrètement représentées et réalisées dans le module

Diagrammes utiles

Diagramme de classe

• Vue détaillée du design
• Plus de classes que dans le modèle d'analyse
• Identifier et caractériser les attributs et méthodes de chaque classe en pensant à l'implémentation

Diagramme de séquence

• Décrit les interactions entre les objets, instances du diagramme de classe
• Un diagramme de séquence par CU

Contraintes et bonnes pratiques

• Grand système partitionné en sous-systèmes développés en parallèle. Le développement d'interfaces est crucial pour la programmation distribuée.
• Implémentation d'un artéfact ou module est toujours suivi de tests.
• Choix du langage de programmation
  • Spécification du contrat. Langage peut être laissé au choix
  • Environnement cible. Le web (frontend) ne supporte que le Javascript, HTML et CSS
  • Expérience/Préférences de l'équipe de développement. Réutilisation de libraires internes
• Normes de programmation et bonnes pratiques
  • Utiliser des noms de variables significatifs et cohérents (ambigus ou génériques).
  • Suivre la nomenclature du langage de programmation (ex: camelCase pour Java)
  • Décrire chaque module en utilisant un format reconnu pour générer la documentation (ex: Javadoc)

Outils et débogage

• Outils de programmation
  • IDE: Environnement combinant tous les outils nécessaires pour le développement.
  • Éditeur: Outil pour écrire et explorer du code. Peut être augmenté (via extensions, pluggins).
• Débogage
  • Assertions: Vérifier une condition lors de l'exécution (if-else). Utiliser des tests unitaires.
  • Exceptions: Détecter une errer logique ou un cas extrèmes (try-catch)
  • Traçage: Produire la trace d'appels (stack trace) retraçant l'historique d'exécution du programme
  • Log manuel: Afficher l'information sur l'état du programme dans un log (ex: fichier texte)
  • Débogueur interactif: Contrôler l'exécution avec des breakpoints et suivre l'état du programme pas à pas. Eclipse debugger
  • Débogage en direct: Modifier le comportement sans quitter le flux d'exécution Démo

Qualités du logiciel

• Pertinence fonctionnelle: Fonctionnalités du logiciel correspondent aux besoins exprimés et tacites du client et des utilisateurs.
• Performance: Logiciel présente des performances relatives aux ressources utilisées.
• Compatibilité: Deux modules peuvent échanger des informations et/ou effectuer leurs tâches, tout en partageant le même environnement (matériel ou logiciel).
• Utilisabilité: Logiciel peut être utilisé de manière efficace et efficiente par ces utilisateurs (humain), en procurant une expérience satisfaisante.
• Fiabilité: Logiciel performe des fonctionnalités attendues dans des conditions attendues sur une durée attendue.
• Sécurité: Logiciel protège l'information pour que les utilisateurs aient les accès requis conformément à leur type/rôle et niveau d'autorisation.
• Maintenabilité: Logiciel peut être modifié efficacement pour l'adapter aux changements dans l'environnement et dans les exigences.
• Transférabilité: Logiciel peut être transféré d'un environnement (logiciel ou matériel) à un autre.

Techniques de vérification

Inspections

• Tester le logiciel sans exécuter de cas de test.
• Révision du logiciel: lire attentivement
• Métriques d'inspection: Taux d'inspection, densité de fautes, taux de détection de fautes
• Revue de code (code review)

Méthodes formelles

• Prouver que le code est correct
• Graphe de flux de controle: Exécution symbolique du programme
• Démonstration automatique de théorèmes

Boite noire vs Boite blanche

• Boite noire (test fonctionnel): Vérifie si le comportement externe du logiciel est conforme aux exigences.
• Boite blanche (test structurel): Vérifie si l'implémentation du logiciel est correcte

Type de tests

• Unitaire: Chaque composant implémenté doit être testé individuellement, dès que complété.
• Intégration: Après chaque itération, combiner les composants et les tester ensemble.
• Système: Tester le système au complet (par développeur)
• Acceptation: Tester l'application à chaque livraison (par client)

Phases d'un logiciel

• Pré-alpha: Encore en développement, avant les tests formels.
• Alpha: En mode tests fonctionnels (boite noire et boite blanche).
• Beta: Logiciel fonctionnel, testé, dans les mains d'un groupe d'utilisateurs controlé.
• Candidat à la livraison: Potentiellement la version finale à moins d'autres défauts. Code source figé.
• En production: Disponible au public. Version commercialisée.

Stratégie et environnements

• Stratégie de versionnement Suivre un standard (MAJOR.MINOR.PATCH) comme le Semantic Versioning
• Environnements
  • Développement: Ordinateur personnel du développeur contenant tout le nécessaire pour le développement.
  • Test (staging): Simule l'environnement de production. Roule souvent sur une machine virtuelle
  • Production: Vrai environnement où le logiciel est installé
• Virtualisation
  • Machine virtuelle: Abstraction complète de la machine. Interagit avec composantes physiques de l'ordinateur via hyperviseurs.
  • Conteneur: Contient toutes les dépendances nécessaires (services, librairies…) pour exécuter une application. Utilise les fonctionnalités de l'OS hote pour en simuler un autre.

DevOps

• Inclure les Ops tout au long du processus de développement
• Instaurer un processus (automatisé) de déploiement en continu suivi par tous
• Intégration continue et Livraison continue (CI/CD)
  • Utiliser des scripts pour automatiser certaines taches
  • Intégration continue (CI): Chacun commit son code fréquemment. Des tests automatisés sont utilisés pour éviter l'introduction de fautes (bugs) ou d'une incompatibilité entre le nouveau code (branche) et le code principal (main).
  • Livraison continue (CD): Infrastructure d'automatisation du déploiement/publication ciblant un ou plusieurs environnements.

Type de changements

• Perfectif: Accroître la valeur du logiciel suite à des changements demandés par le client.
• Adaptif: Préserver la valeur du logiciel en répondant aux changements de l'environnement
• Correctif: Corriger les défauts restants
• Préventif: Protège le logiciel en facilitant les changements futurs par anticipation

Logiciels de suivi de défauts Exemples: Bugzilla, Backlog, BugHerd

• Création de tickets, assignation et suivi de la résolution
• Rapport de défauts: Doit inclure assez d'information pour permettre au programmeur de maintenance de recréer le problème pour l'investiguer

Étapes clés pour effectuer un changement

Recherche des modules cibles

• Recherche textuelle: Indépendant de la structure du programme, mais dépend des conventions de nommage. Applicable à des concepts explicites seulement
• Graphe par dépendance (graphe): Utilise la structure des classes du programme et nécessite la compréhension des fonctionnalités locales et composites. Applicable aux concepts implicites et explicites

Refactoring

• Modifie la structure du code sans affecter la fonctionnalité
• Certains changements sont apportés afin de minimiser l'impact des changements
• Consiste en une séquence de transformations qui préservent le comportement

Test de régression

• Garantir que le changement est correct. Après un changement, le programmeur re-teste tout le code.
• Cas de test antérieurs font partie du test de régression. La suite de tests augmente

Caractéristique

• Bonne conception 👍
  • Faible couplage et forte cohésion
  • Réutilisation: Réutilisation d'un composant d'un produit pour faciliter le développement d'un autre produit ayant des fonctionnalités différentes
  • Conception modulaire: Décomposition en modules indépendants et interchangeables qui contiennent tout ce qui leur est nécessaire pour exécuter un aspect d'une fonctionnalité
  • Conception évolutive: Minimiser l'effort d'apporter des modifications au logiciel après le développement initial
• Mauvaise conception 👎
  • Rigidité: Logiciel difficile à modifier car chaque changement impacte beaucoup trop de parties du système
  • Fragilité: Quand on effectue une modification, des parties imprévues du système ne fonctionnent plus
  • Immobilité: Difficile de réutiliser un composant dans une autre application car on ne peut la démêler de l'application courante

Conception modulaire vs. monolithique

• Les deux designs sont équivalent d'un point de vue fonctionnel
• Design monolithique
  • Difficile à comprendre
  • Difficile à étendre ou améliorer
  • Difficile à réutiliser dans un autre produit
• Design modulaire
  • Maximiser les relations au sein du module
  • Minimiser les relations entre les modules
  • Facilite la modification d'un système
  • Favorise la réutilisation d'un module

Réutilisation

• Librairie: Ensemble de programmes/modules cohésifs et réutilisables. Utilisateur de la librairie est responsable de la logique de contrôle.
• Framework: La plateforme incorpore la logique de contrôle générique. Utilisateur personnalise les fonctionnalités génériques pour les besoins de l'application.
• Programmation orientée composant: Combine les deux approches. Mise en place d'une plateforme applicative et identification des librairies réutilisables que la plateforme peut invoquer.

• Pipes et filtres
  • Modules organisés en filtres communiquant via des pipes.
  • Traitement batch en plusieurs étapes
  • Exécution concurrente de filtres, synchronisation des flux parfois nécessaire
  • Usages: Compilateur, Traitement d'image, Lignes de déploiement
• En couche (ex: 3-tier)
  • Système organisé en couches hiérarchiques.
  • Chaque couche fournit un service à la couche supérieur et en reçoit de la couche inférieure
  • Usages: Réseaux, Application Web
• MVC (Model-View-Controller) Divise une application en trois composant: Modèle, Vue et Controleur.
  • Modèle: encapsule l'état de l'application et répond aux demandes d'état
  • Vue: fait le rendu du modèle et affiche l'information à l'utilisateur
  • Controleur: définit le comportement de l'application et traite les requêtes.
  • Usages: Majorité des applications web, Framework
• Client-serveur Divise le système en deux parties: Serveur et Clients
  • Clients: reçoivent des services des serveurs et doivent pouvoir contacter les serveurs
  • Serveurs: fournissent des services aux clients et autres serveurs
  • Usages: Email, Système bancaire
• Peer-to-peer
  • Chaque nœud (peer) joue à la fois le rôle du client et du serveur
  • Favorise la fiabilité du système (tolérance aux pannes)
  • Mise à l'échelle facile (grandit avec le nombre de pairs)
  • Usages: Blockchain, BitTorrent
• Microservice
  • Collection de petits services autonomes, indépendants et restraints à une fonction
  • Service accessible via une API (fournisseur de service), accessible par internet
  • Usages: Amazon web services (AWS), Azure

Caractéristiques

• Objet: Représente une entité réelle ou conceptuelle, singulière et identifiable avec un rôle bien défini dans le domaine du problème
• Classe: Représentation d'un ensemble d'objets qui partagent une structure, un comportement et une sémantique en commun
• Héritage: Relation de partage de la structure et du comportement
• Polymorphisme: Une opération définie dans plus d'une classe qui prend différentes implémentations
• Encapsulation: Regroupement de concepts reliés en une seule unité référée par un seul nom
• Abstraction: Utilisation de l'encapsulation pour restreindre la perception depuis l'extérieur sur les mécanismes internes au logiciel
• Généricité: Mécanisme pour que les clients décident du type d'objets dans une classe à travers des paramètres passé lors de la déclaration et qui est évalué lors de la compilation

Patron de création

• Singleton Garantir qu'une classe n'a qu'une seule instance et offre un point d'accès global
  • Contrôle l'accès à l'instance
  • Accès global sans utiliser de variable globale
  • Facilite le raffinement des opérations et représentations
• Fabrique Permet de dissimuler comment créer les objets.
  • Définir une interface pour créer un objet, mais en laissant les sous-classes décider quelle classe instancier
  • Permet au code d'être indépendant de comment les objets sont créés, composés et représentés
  • Délègue l'instanciation à une sous-classe

Patron de structure

• Composite Compose les objets en structures d'arborescence pour représenter des hiérarchies d'ensemble/partie.
  • Permet au client de traiter les objets et les compositions de façon uniforme
  • Définit une hiérarchie claire des objets
  • Composition récursive d'objets simples et complexes
• Adapteur Communication entre deux objets ayant leurs implémentations incompatibles
  • Donne accès à son implémentation interne sans pour autant coupler les clients à son implémentation interne
  • Adaptateur fournit tous les avantages de la dissimulation de l'information sans avoir à cacher ses détails d'implémentation

Patron de comportement

• Patron de méthode Définit le squelette d'un algorithme dans une opération en reportant certaines étapes à des sous-classes.
  • Permet d'affiner certaines étapes d'un algorithme sans changer sa structure
  • Implémente les parties invariantes d'un algorithme et laisse les sous-classes implémenter le comportement qui va varier
  • Évite la duplication de code en factorisant le comportement commun des sous-classes
• Stratégie Définit une famille d'algorithmes, encapsule chacun et rend-les interchangeables.
  • Algorithme varie indépendamment du client qui l'utilise