Software Engineering 101

Software Engineering
Lecture
Introduction to software engineering principles and practices
Auteur
Affiliations

Emmanuel BRUNO

Université de Toulon

LIS UMR CNRS 7020

Date de publication

2026-10-03

Génie Logiciel : Fondamentaux et Pratiques Modernes

Ce cours explore les fondements du génie logiciel, combinant théorie et pratique pour une compréhension complète du développement logiciel moderne.

Objectifs pédagogiques: - Maîtriser les concepts fondamentaux - Comprendre les différentes approches - Acquérir des compétences pratiques - Développer un esprit critique

Introduction au génie logiciel

Le génie logiciel aujourd’hui

Le génie logiciel est une discipline en constante évolution qui répond aux défis modernes du développement logiciel:

1. Complexité des systèmes - Architectures distribuées - Intégration de multiples technologies - Systèmes hautement concurrents - Sécurité renforcée

2. Contraintes du marché - Time-to-market réduit - Innovation continue - Adaptation rapide aux changements - Compétition mondiale

3. Exigences de qualité - Fiabilité critique - Performance optimale - Sécurité robuste - Expérience utilisateur fluide

4. Pratiques modernes - Agilité et DevOps - Architecture cloud-native - Automatisation poussée - Développement durable

mindmap
  root((Génie Logiciel))
    Processus
      Agile
        Scrum
        Kanban
      DevOps
        CI/CD
        Infrastructure as Code
    Qualité
      Tests
        Unitaires
        E2E
      Standards
        Clean Code
        SOLID
    Architecture
      Cloud Native
        Containers
        Serverless
      Microservices
        API First
        Event-Driven
    Pratiques
      Clean Code
        Refactoring
        Code Review
      CI/CD
        Tests auto
        Déploiement continu

Définition et objectifs du génie logiciel

Le génie logiciel est une discipline qui intègre les principes d’ingénierie et de gestion pour créer des logiciels fiables et efficaces.

flowchart LR
  A[Problème] --> B[Analyse]
  B --> C[Conception]
  C --> D[Implémentation]
  D --> E[Test]
  E --> F[Déploiement]
  F --> G[Maintenance]

Qualités d’un logiciel

Les qualités essentielles d’un logiciel moderne s’articulent autour de plusieurs dimensions:

graph TB
    A[Qualités<br>Logicielles] --> B[Externes]
    A --> C[Internes]
    B --> D[Fiabilité]
    B --> E[Performance]
    B --> F[Utilisabilité]
    C --> G[Maintenabilité]
    C --> H[Testabilité]
    C --> I[Portabilité]
    
    style A fill:#f9f,stroke:#333,stroke-width:4px
    style B fill:#bbf,stroke:#333
    style C fill:#bbf,stroke:#333

Qualité Description Mesures
Fiabilité Capacité à fonctionner sans défaillance MTBF, taux d’erreurs
Maintenabilité Facilité à être modifié et corrigé Complexité cyclomatique, dette technique
Performance Optimisation des ressources Temps de réponse, utilisation mémoire
Sécurité Protection contre les menaces Vulnérabilités, conformité OWASP
Scalabilité Capacité d’adaptation à la charge Temps de réponse sous charge
Testabilité Facilité à être testé Couverture de tests, isolabilité

Principes de base du développement logiciel

  • Abstraction: Représenter les concepts essentiels sans détails d’implémentation
  • Modularité: Décomposer en modules cohérents et faiblement couplés
  • Encapsulation: Masquer les détails d’implémentation
  • Séparation des préoccupations: Diviser le système en parties distinctes

Cycle de vie du logiciel

Le cycle de vie comprend toutes les phases depuis la conception jusqu’à la fin de vie du logiciel.

stateDiagram-v2
    direction LR
    
    classDef analysisPhase fill:#d4f1f9,stroke:#05668d,stroke-width:2px
    classDef designPhase fill:#ffdac1,stroke:#d95204,stroke-width:2px
    classDef devPhase fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
    classDef testPhase fill:#e8daef,stroke:#6a1b9a,stroke-width:2px
    classDef deployPhase fill:#ffecb3,stroke:#ff8f00,stroke-width:2px
    classDef maintainPhase fill:#f5b7b1,stroke:#922b21,stroke-width:2px
    
    Analyse --> Conception
    Conception --> Implémentation
    Implémentation --> Test
    Test --> Déploiement
    Déploiement --> Maintenance
    Maintenance --> Analyse: Évolution
    
    note right of Analyse: <b>Définition des besoins</b>\nCompréhension du problème\nSpécification des exigences
    note right of Conception: <b>Architecture et design</b>\nStructure du système\nInterfaces et composants
    note right of Implémentation: <b>Développement</b>\nÉcriture du code\nUnités fonctionnelles
    note right of Test: <b>Validation</b>\nVérification fonctionnelle\nAssurance qualité
    note right of Déploiement: <b>Mise en production</b>\nInstallation\nConfiguration
    note right of Maintenance: <b>Évolution</b>\nCorrections\nAméliorations\nAdaptation
    
    state "Analyse" as Analyse
    state "Conception" as Conception
    state "Implémentation" as Implémentation
    state "Test" as Test
    state "Déploiement" as Déploiement
    state "Maintenance" as Maintenance
    
    class Analyse analysisPhase
    class Conception designPhase
    class Implémentation devPhase
    class Test testPhase
    class Déploiement deployPhase
    class Maintenance maintainPhase
Figure 1: Cycle de vie du logiciel

Processus de développement

Évolution des méthodologies

Les processus de développement ont considérablement évolué pour répondre aux défis modernes:

1. Approches traditionnelles - Cycle en cascade - Modèle en V - Processus unifié

2. Méthodes agiles - Scrum et ses rituels - Kanban et le flux continu - XP et les pratiques d’ingénierie

3. Approches hybrides - Scrumban - SAFe - DevOps

Modèles classiques (Waterfall, V-model)

Le modèle en cascade suit une approche linéaire et séquentielle:

  1. Analyse des besoins
  2. Conception
  3. Implémentation
  4. Test
  5. Déploiement
  6. Maintenance

Avantages: Structure claire, documentation complète
Inconvénients: Peu flexible, retour client tardif

Le modèle en V associe chaque phase de développement à une phase de test:

Voici un diagramme Mermaid pour le modèle en V qui illustre clairement la correspondance entre les phases de développement et de test:

flowchart TD
    classDef devPhase fill:#ffdac1,stroke:#d95204,stroke-width:2px
    classDef testPhase fill:#e8daef,stroke:#6a1b9a,stroke-width:2px
    classDef centerPhase fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    A[Analyse des besoins] -->|développement| B[Conception système]
    B -->|développement| C[Conception détaillée]
    C -->|développement| D[Codage]
    D -->|validation| E[Tests unitaires]
    E -->|validation| F[Tests d'intégration]
    F -->|validation| G[Tests système]
    G -->|validation| H[Tests d'acceptation]
    
    A -.->|validation| H
    B -.->|validation| G
    C -.->|validation| F

    subgraph Développement
        A
        B
        C
    end
    
    subgraph Implémentation
        D
    end
    
    subgraph Validation
        E
        F
        G
        H
    end

    class A,B,C devPhase
    class D centerPhase
    class E,F,G,H testPhase

    NoteA["Définition des exigences<br>Expression des besoins"]
    NoteB["Architecture globale<br>Interfaces principales"]
    NoteC["Design des composants<br>Algorithmes"]
    NoteD["Programmation<br>Implémentation"]
    NoteE["Validation des modules<br>individuels"]
    NoteF["Validation des<br>interactions"]
    NoteG["Validation de<br>l'architecture"]
    NoteH["Validation des<br>besoins initiaux"]

    A -.-> NoteA
    B -.-> NoteB
    C -.-> NoteC
    D -.-> NoteD
    E -.-> NoteE
    F -.-> NoteF
    G -.-> NoteG
    H -.-> NoteH

    classDef noteStyle fill:#f0f0f0,stroke:#aaa,stroke-dasharray:5
Figure 2: Modèle en V: correspondance entre développement et validation

Avantages: Emphase sur les tests, traçabilité
Inconvénients: Rigidité, adaptation difficile au changement

Approches agiles (Scrum, Kanban)

Les méthodes agiles favorisent:

  • Livraison incrémentale et itérative
  • Adaptation aux changements
  • Collaboration étroite avec le client
  • Amélioration continue
AstuceManifeste Agile
  • Individus et interactions plutôt que processus et outils
  • Logiciel fonctionnel plutôt que documentation exhaustive
  • Collaboration avec le client plutôt que négociation de contrat
  • Adaptation au changement plutôt que suivi d’un plan

Scrum

  • Sprints: Cycles de travail de 2-4 semaines
  • Rôles clés:
    • Product Owner (responsable du produit)
    • Scrum Master (facilitateur)
    • Équipe de développement (auto-organisée)
  • Rituels:
    • Daily Stand-up (synchronisation quotidienne)
    • Sprint Planning (planification)
    • Sprint Review (démonstration)
    • Sprint Retrospective (amélioration)
  • Forces: Cadre structuré, livraison rapide, collaboration

Voici une amélioration de la section Kanban sous forme d’un slide complet et visuellement engageant :

Kanban

flowchart LR
    subgraph "Backlog" ["Backlog"]
        B1["User story #1"]
        B2["User story #2"]
        B3["User story #3"]
        B4["..."]
    end
    
    subgraph "À faire" ["À faire (WIP: 3/3)"]
        T1["Tâche #4"]
        T2["Tâche #5"]
        T3["Tâche #6"]
    end
    
    subgraph "En cours" ["En cours (WIP: 2/2)"]
        P1["Tâche #7"]
        P2["Tâche #8"]
    end
    
    subgraph "Test" ["Test (WIP: 1/2)"]
        R1["Tâche #9"]
    end
    
    subgraph "Terminé" ["Terminé"]
        D1["Tâche #1"]
        D2["Tâche #2"]
        D3["Tâche #3"]
    end
    
    Backlog --> "À faire"
    "À faire" --> "En cours"
    "En cours" --> "Test"
    "Test" --> "Terminé"
    
    style "À faire" fill:#ffcccb,stroke:#333
    style "En cours" fill:#ffffcc,stroke:#333
    style "Test" fill:#ccffcc,stroke:#333
    style "Terminé" fill:#ccccff,stroke:#333
    
    %% Indicateurs métriques
    CycleTime["Cycle Time: 2.3 jours"]
    LeadTime["Lead Time: 6.5 jours"]
    Throughput["Débit: 8 tâches/semaine"]

Tableau Kanban avec limites WIP

Principes fondamentaux:

  • Visualisation du flux de travail : Représentation claire de chaque étape du processus
  • Limitation du travail en cours (WIP) : Prévention de la surcharge et identification des goulots d’étranglement
  • Gestion du flux : Optimisation pour un mouvement fluide et prévisible des tâches
  • Politiques explicites : Règles claires pour chaque étape du processus
  • Boucles de feedback : Réunions, métriques et révisions régulières
  • Amélioration collaborative : Évolution progressive basée sur des données empiriques

Métriques clés:

  • Lead time : Temps total depuis la demande jusqu’à la livraison
  • Cycle time : Temps de traitement effectif d’une tâche
  • Throughput : Nombre de tâches complétées par unité de temps
  • Taux de blocage : Pourcentage de tâches bloquées

Forces: Flexibilité, visualisation immédiate des problèmes, adaptation continue, réduction du gaspillage, prévisibilité accrue

Idéal pour: Environnements avec flux de travail continu, équipes de maintenance, projets à priorités changeantes

XP (Extreme Programming)

  • Pratiques techniques rigoureuses:
    • Programmation en binôme
    • Développement piloté par les tests (TDD)
    • Intégration continue
    • Refactoring fréquent
  • Cycles courts et feedback constant
  • Client sur site pour consultation immédiate
  • Design simple et évolutif
  • Forces: Qualité technique élevée, adaptabilité, réduction des défauts

flowchart TD
    A[Exigences] --> B[Planning]
    B --> C[Conception simple]
    C --> D[Tests]
    D --> E[Programmation en binôme]
    E --> F[Intégration continue]
    F --> G[Livraison fréquente]
    G --> A

Scrumban

  • Hybride entre Scrum et Kanban
  • Combine itérations de Scrum et flux continu de Kanban
  • Planification à la demande (quand le backlog s’épuise)
  • Métriques de flux pour optimiser le processus
  • Forces: Flexibilité accrue de Scrum, visualisation améliorée

flowchart LR
    A[Backlog] --> B[Planifié]
    B --> C[En cours]
    C --> D[Test]
    D --> E[Terminé]
    
    subgraph "Priorités dynamiques"
        A
    end
    subgraph "Sprint flexible"
        B
        C
        D
    end
    subgraph "Mesure continue"
        E
    end

Processus unifié

Le Processus Unifié (RUP) combine aspects itératifs et incrémentiels:

  • Phases: Inception, Élaboration, Construction, Transition
  • Aspects: Risques, Architecture, Valeur métier, Compétences
  • Disciples: Modélisation, Implémentation, Test, Déploiement, etc.

RAD (Rapid Application Development)

  • Définition: Méthodologie créée par James Martin (1991) pour accélérer le développement
  • Objectif: Livrer rapidement des applications fonctionnelles (60-90 jours)
  • Principes: Prototypage rapide, implication continue des utilisateurs, équipes pluridisciplinaires
  • Phases: 1) Planification des besoins → 2) Conception utilisateur (prototypes) → 3) Construction rapide → 4) Transition
  • Forces: Développement rapide, forte adhésion utilisateur, visibilité précoce des résultats
  • Limites: Évolutivité limitée, nécessite utilisateurs disponibles et développeurs expérimentés
  • Cas d’usage: Projets de taille moyenne, besoins utilisateurs évolutifs, applications avec forte composante UI
  • Évolution: A inspiré DSDM, certains aspects d’XP, et les plateformes low-code/no-code modernes
  • Différenciation: Plus structuré que les méthodes purement agiles, mais plus flexible que le cycle en cascade
flowchart LR
    A[1. Planification<br>• Définition périmètre<br>• Ateliers JAD] --> B[2. Conception utilisateur<br>• Prototypage<br>• Validation immédiate]
    B --> C[3. Construction<br>• Développement rapide<br>• Tests continus]
    C --> D[4. Transition<br>• Finalisation<br>• Formation]
    D -.-> B
    style A fill:#f9d5e5,stroke:#333
    style B fill:#eeeeee,stroke:#333
    style C fill:#e3eaa7,stroke:#333
    style D fill:#b5ead7,stroke:#333

Analyse et spécification des besoins

  • L’ingénierie des exigences comprend:

    1. Élicitation: Découvrir les besoins des parties prenantes
    2. Analyse: Clarifier et prioriser les exigences
    3. Spécification: Documenter les exigences
    4. Validation: Vérifier la cohérence et la pertinence
    5. Gestion: Suivre l’évolution des exigences

Techniques de collecte des besoins

  • Interviews et questionnaires
  • Ateliers et brainstorming
  • Observation et ethnographie
  • Prototypage et scénarios d’utilisation
  • Analyse de documents existants
ImportantRègles SMART pour les exigences
  • Spécifique
  • Mesurable
  • Atteignable
  • Réaliste
  • Temporellement défini

Conception logicielle

  • Définition: Processus de transformation des exigences en représentation implémentable
  • Objectif: Créer un plan détaillé pour guider l’implémentation
  • Position: Phase intermédiaire entre analyse des besoins et codage
  • Résultat: Ensemble de modèles, schémas et spécifications techniques

Approches fondamentales

  • Conception descendante (Top-Down)
    • Commence par la vision globale, Décompose progressivement en sous-systèmes, Favorise la compréhension des objectifs généraux
  • Conception ascendante (Bottom-Up)
    • Commence par les composants de bas niveau, Les assemble progressivement en systèmes plus grands, Favorise la réutilisation et le pragmatisme
  • Conception orientée objet (OOD)
    • Organisation autour d’objets plutôt que d’actions, Encapsulation des données avec comportements associés, Relations basées sur héritage, composition, agrégation

Niveaux de conception

  • Architecture logicielle
    • Structure globale du système
    • Décomposition en sous-systèmes/modules
    • Définition des interfaces principales
    • Choix des styles architecturaux (couches, microservices, etc.)
  • Conception détaillée
    • Spécification précise des classes/modules
    • Algorithmes et structures de données
    • Protocoles de communication
    • Relations entre composants

Méthodologies de conception logicielle

timeline
    title Évolution des méthodologies de conception
    1970s : Structured Design
    1980s : Object-Oriented Design
    1990s : Design Patterns : UML
    2000s : Agile Methods : TDD : Refactoring
    2010s : DDD : BDD : Microservices
    2020s : API-first : Event-driven : Continuous Design

Domain-Driven Design (DDD)

Philosophie: Alignement du code sur le modèle mental du métier

Étapes clés: 1. Établir un langage omniprésent 2. Identifier les bounded contexts 3. Modéliser le domaine (entités, agrégats, services) 4. Implémenter en préservant l’intégrité du modèle

Test-Driven Development (TDD)

Philosophie: Les tests guident la conception

Étapes clés: 1. Écrire un test qui échoue (RED) 2. Écrire le code minimal pour passer le test (GREEN) 3. Améliorer le code sans changer son comportement (REFACTOR) 4. Répéter

Behavior-Driven Development (BDD)

Philosophie: Les comportements attendus définissent le logiciel

Étapes clés: 1. Spécifier le comportement en langage naturel structuré (Given-When-Then) 2. Automatiser les spécifications en tests exécutables 3. Développer pour satisfaire les comportements 4. Utiliser les scénarios comme documentation vivante

Model-Driven Architecture (MDA)

Philosophie: Les modèles abstraits sont la source de vérité

Étapes clés:

  1. Créer un modèle indépendant de la plateforme (PIM)
  2. Transformer en modèle spécifique à la plateforme (PSM)
  3. Générer le code à partir du PSM
  4. Affiner et compléter l’implémentation

Feature-Driven Development (FDD)

Philosophie: Organiser le développement autour des fonctionnalités utilisateur

Étapes clés:

  1. Développer un modèle global
  2. Construire une liste de fonctionnalités
  3. Planifier par fonctionnalité
  4. Concevoir par fonctionnalité
  5. Implémenter par fonctionnalité

Continuous Design

Philosophie: La conception évolue progressivement avec le code

Étapes clés:

  1. Commencer avec un design minimal viable
  2. Intégrer continuellement les changements
  3. Refactoriser régulièrement
  4. Utiliser les métriques pour guider l’évolution
  5. Adapter la conception aux nouveaux besoins

Event Storming

Philosophie: Exploration collaborative du domaine par les événements

Étapes clés:

  1. Identifier les événements du domaine (post-its)
  2. Ajouter les commandes qui déclenchent ces événements
  3. Identifier les agrégats et règles métier
  4. Organiser en bounded contexts
  5. Dériver le modèle de domaine

Voici une section améliorée et détaillée sur la modélisation UML pour votre cours :

Modélisation avec UML

Le langage UML (Unified Modeling Language) est une notation standardisée pour visualiser, spécifier, construire et documenter les artefacts d’un système logiciel. Développé dans les années 1990 et maintenu par l’OMG (Object Management Group), il constitue aujourd’hui le standard de facto pour la modélisation orientée objet.

Diagrammes structurels

Les diagrammes structurels représentent l’architecture statique du système :

Objectif : Représenter les classes, leurs attributs, méthodes et relations.

Éléments clés : - Classes et interfaces - Attributs et méthodes avec visibilité - Relations : association, agrégation, composition, héritage, etc. - Cardinalités et rôles

classDiagram
    class Véhicule {
        -marque: String
        -modèle: String
        +démarrer(): void
        +arrêter(): void
    }
    
    class Voiture {
        -nombrePortes: int
        +ouvrirCoffre(): void
    }
    
    class Moto {
        -cylindrée: int
        +faireUnWheeling(): void
    }
    
    Véhicule <|-- Voiture : hérite de
    Véhicule <|-- Moto : hérite de
    
    class Conducteur {
        -nom: String
        -permis: String
        +conduire(v: Véhicule): void
    }
    
    Conducteur "1" --> "0..n" Véhicule : conduit >

Objectif : Montrer une “photo instantanée” d’instances de classes et leurs relations à un moment donné.

Éléments clés : - Instances d’objets nommées - Valeurs d’attributs concrètes - Liens entre objets (instances d’associations)

classDiagram
    class "renault: Voiture" {
        marque = "Renault"
        modèle = "Clio"
        nombrePortes = 5
    }
    
    class "ducati: Moto" {
        marque = "Ducati"
        modèle = "Monster"
        cylindrée = 900
    }
    
    class "jean: Conducteur" {
        nom = "Jean Dupont"
        permis = "B, A"
    }
    
    "jean: Conducteur" --> "renault: Voiture" : conduit
    "jean: Conducteur" --> "ducati: Moto" : conduit

Objectif : Représenter l’organisation physique des composants d’un système et leurs dépendances.

Éléments clés : - Composants logiciels - Interfaces fournies et requises - Relations de dépendance

flowchart TD
    subgraph UI[Interface utilisateur]
        Vue[Vue]
    end
    
    subgraph Business[Couche métier]
        Service[Service]
        ViewModel[ViewModel]
    end
    
    subgraph Data[Couche données]
        Repository[Repository]
        DAO[DAO]
    end
    
    Database[(Base de données)]
    
    Vue -- utilise --> ViewModel
    ViewModel -- utilise --> Service
    Service -- utilise --> Repository
    Repository -- utilise --> DAO
    DAO -- accède --> Database
    
    style UI fill:#f9d5e5,stroke:#333
    style Business fill:#eeeeee,stroke:#333
    style Data fill:#e3eaa7,stroke:#333

Objectif : Montrer la configuration physique du matériel et la distribution des composants logiciels.

Éléments clés : - Nœuds (hardware) - Artefacts (composants déployés) - Connexions réseau

flowchart TD
    subgraph "Poste client"
        Browser[Navigateur web]
    end
    
    subgraph "Serveur d'application"
        WebServer[Serveur Web]
        AppServer[Serveur d'application]
    end
    
    subgraph "Serveur de données"
        DB[Base de données]
    end
    
    Browser -- HTTPS --> WebServer
    WebServer -- API --> AppServer
    AppServer -- JDBC --> DB
    
    style "Poste client" fill:#d4f1f9,stroke:#05668d
    style "Serveur d'application" fill:#c8e6c9,stroke:#2e7d32
    style "Serveur de données" fill:#ffecb3,stroke:#ff8f00

Objectif : Organiser les éléments du modèle en groupes pour simplifier les diagrammes complexes.

Éléments clés : - Paquetages (namespaces/modules) - Dépendances entre paquetages - Visibilité des éléments

classDiagram
    namespace UI {
        class Vue
        class Controller
    }
    
    namespace Core {
        class Service
        class Model
    }
    
    namespace Data {
        class Repository
        class Entity
    }
    
    UI --> Core : utilise
    Core --> Data : utilise

Diagrammes comportementaux

Les diagrammes comportementaux illustrent le fonctionnement dynamique du système :

Objectif : Décrire les fonctionnalités du système du point de vue utilisateur.

Éléments clés : - Acteurs (utilisateurs ou systèmes externes) - Cas d’utilisation (fonctionnalités) - Relations entre cas d’utilisation (inclusion, extension)

flowchart TD
    User[Utilisateur] --- UC1[S'authentifier]
    User --- UC2[Consulter catalogue]
    User --- UC3[Passer commande]
    Admin[Administrateur] --- UC4[Gérer produits]
    Admin --- UC5[Suivre commandes]
    
    UC3 -.-> UC1: <<include>>
    UC5 -.-> UC3: <<extend>>
    
    style User fill:#f9d5e5
    style Admin fill:#f9d5e5
    style UC1 fill:#d4f1f9,stroke:#05668d
    style UC2 fill:#d4f1f9,stroke:#05668d
    style UC3 fill:#d4f1f9,stroke:#05668d
    style UC4 fill:#d4f1f9,stroke:#05668d
    style UC5 fill:#d4f1f9,stroke:#05668d

Objectif : Modéliser les interactions entre objets dans le temps, montrant l’ordre des messages échangés.

Éléments clés : - Objets (instances de classes) - Lignes de vie et messages - Activations (périodes d’exécution) - Fragments d’interaction (alternatives, boucles)

sequenceDiagram
    actor Client
    participant Interface
    participant Controller
    participant Service
    participant Repository
    participant Database
    
    Client->>Interface: saisirCommande()
    activate Interface
    Interface->>Controller: créerCommande(données)
    activate Controller
    Controller->>Service: validerCommande(données)
    activate Service
    
    alt Commande valide
        Service->>Repository: sauvegarderCommande(commande)
        activate Repository
        Repository->>Database: insert(commande)
        Database-->>Repository: confirmation
        Repository-->>Service: commandeSauvegardée
        deactivate Repository
        Service-->>Controller: commandeValidée
    else Commande invalide
        Service-->>Controller: erreurValidation
    end
    
    deactivate Service
    Controller-->>Interface: résultatCommande
    deactivate Controller
    Interface-->>Client: afficherConfirmation()
    deactivate Interface

Objectif : Décrire les flux de travail, processus métier ou algorithmes avec leurs points de décision.

Éléments clés : - Actions et activités - Transitions et conditions - Bifurcations et jointures (parallélisme) - Partitions (swimlanes)

stateDiagram-v2
    [*] --> ReceptionCommande
    
    state "Traitement commande" as Process {
        ReceptionCommande --> VerificationStock
        
        state "Vérification parallèle" as fork_state
        VerificationStock --> fork_state
        fork_state --> VerificationPaiement
        fork_state --> ReservationStock
        
        VerificationPaiement --> join_state
        ReservationStock --> join_state
        
        state join_state <<join>>
        join_state --> PreparationCommande
        PreparationCommande --> Expédition
    }
    
    Expédition --> Livraison
    Expédition --> [*] : Annulation
    Livraison --> [*]

Objectif : Illustrer les différents états d’un objet au cours de son cycle de vie et les transitions entre ces états.

Éléments clés : - États (représentant une condition ou situation) - Transitions (changements d’état) - Événements déclencheurs - Actions et activités dans les états

stateDiagram-v2
    [*] --> Créée
    Créée --> EnAttente : soumettre()
    EnAttente --> EnCours : accepter()
    EnAttente --> Annulée : refuser()
    EnCours --> Expédiée : expédier()
    EnCours --> Annulée : annuler()
    Expédiée --> Livrée : livrer()
    Expédiée --> Retournée : retourner()
    Livrée --> [*]
    Annulée --> [*]
    Retournée --> [*]
    
    state Créée {
        [*] --> AvecProduits : ajouterProduits()
        AvecProduits --> AvecAdresseLivraison : spécifierAdresse()
        AvecAdresseLivraison --> PrêteÀSoumettre : spécifierPaiement()
    }

Objectif : Montrer les interactions entre objets en se concentrant sur la structure des échanges plutôt que sur leur chronologie.

Éléments clés : - Objets et leurs liens - Messages numérotés - Conditions et itérations

flowchart LR
    Client -- "1: créerCommande()" --> Panier
    Panier -- "2: ajouterProduit()" --> LignePanier
    Panier -- "3: calculerTotal()" --> LignePanier
    Panier -- "4: valider()" --> CommandeService
    CommandeService -- "5: convertirEnCommande()" --> Panier
    CommandeService -- "6: enregistrer()" --> CommandeRepository

Bonnes pratiques UML

  1. Niveau de détail adapté : Inclure uniquement les informations pertinentes pour l’audience cible
  2. Cohérence : Maintenir une terminologie et des conventions cohérentes entre diagrammes
  3. Modularité : Diviser les modèles complexes en sous-modèles plus simples
  4. Annotation : Ajouter des notes pour clarifier les aspects ambigus
  5. Évolution progressive : Commencer par des modèles simples et les affiner itérativement

Outils de modélisation UML

  • Outils dédiés : Enterprise Architect, Visual Paradigm, Modelio
  • IDE avec support UML : IntelliJ IDEA, Eclipse avec plugins
  • Outils collaboratifs : Lucidchart, draw.io
  • Langages textuels : PlantUML, Mermaid

Implémentation

  • Définition: Phase de transformation des spécifications en code exécutable
  • Objectif: Produire un logiciel fonctionnel selon les spécifications établies
  • Résultats: Code source, documentation technique, tests automatisés

Bonnes pratiques de programmation

  • DRY (Don’t Repeat Yourself): Éviter la duplication de code
  • KISS (Keep It Simple, Stupid): Privilégier la simplicité
  • YAGNI (You Aren’t Gonna Need It): Ne pas anticiper des besoins hypothétiques
  • Separation of Concerns: Diviser le code en responsabilités distinctes
  • Fail Fast: Détecter et signaler les erreurs au plus tôt

Tests et Qualité

Assurance qualité approfondie

L’assurance qualité englobe plusieurs aspects:

  1. Stratégie de test
    • Pyramide de tests
    • Couverture du code
    • Automatisation
  2. Métriques
    • Complexité cyclomatique
    • Dette technique
    • Taux de défauts

Gestion de projet logiciel

  • Définition: Ensemble des activités de planification, d’organisation, de suivi et de contrôle d’un projet de développement logiciel.
  • Objectif: Livrer un produit conforme aux exigences, dans les délais et le budget alloués.

Approches de gestion de projet

  • Prédictives (plan-driven)
    • Approche traditionnelle (cascade, cycle en V)
    • Planification détaillée en amont
    • Contrôle du respect du plan
    • Adapté aux projets à exigences stables
  • Adaptatives (change-driven)
    • Approches agiles (Scrum, Kanban, XP)
    • Planification progressive
    • Inspection et adaptation continues
    • Adapté aux projets à forte incertitude

Planification et estimation

  • Techniques d’estimation
    • Analogique: Comparaison avec projets similaires
    • Paramétrique: Utilisation de métriques (points de fonction, lignes de code)
    • Bottom-up: Décomposition et estimation des éléments individuels
    • Expert: Jugement basé sur l’expérience
    • Planning poker: Estimation collaborative et consensuelle
  • Outils de planification
    • WBS (Work Breakdown Structure) : Décomposition hiérarchique des tâches
    • Diagrammes de Gantt (PERT, CPM) : Visualisation des dépendances et durées
    • Backlog produit et planification de sprint : Liste des fonctionnalités et ordonnancement par priorité
    • Story mapping : Visualisation des fonctionnalités par scénarios utilisateur
    • Méthode du chemin critique (CPM) : Identification des tâches critiques
    • Story mapping : Visualisation des fonctionnalités par scénarios utilisateur

Maintenance et évolution

  • Types de maintenance
    • Corrective: Correction des défauts
    • Adaptative: Adaptation aux changements d’environnement
    • Perfective: Amélioration des fonctionnalités
    • Préventive: Prévention des problèmes futurs

Refactoring

Le refactoring améliore la structure du code sans en modifier le comportement externe:

  • Extraction de méthode
  • Simplification des conditions
  • Élimination du code dupliqué
  • Réorganisation des classes

La gestion des versions

La gestion des versions est un aspect crucial du développement logiciel moderne, permettant de:

  • Suivre l’évolution du code source et des composants
  • Coordonner le travail des équipes
  • Faciliter la livraison de nouvelles fonctionnalités
  • Assurer la traçabilité des changements
  • Maintenir plusieurs versions du produit

Versionnement sémantique (SemVer)

  • Principe: MAJOR.MINOR.PATCH
    • MAJOR: Changements incompatibles avec l’API précédente
    • MINOR: Ajouts de fonctionnalités compatibles
    • PATCH: Corrections de bugs compatibles
  • Exemples:
    • 0.0.1: Version initiale
    • 1.0.0: Version initiale stable
    • 1.1.0: Ajout de nouvelles fonctionnalités
    • 1.1.1: Correction de bugs
    • 2.0.0: Changements cassant la compatibilité
  • Suffixes additionnels:
    • -alpha: Version instable en développement interne
    • -beta: Version en test externe
    • -rc.1: Release candidate (quasi-finale)

Systèmes de gestion de versions (VCS)

  • Centralisés: SVN, CVS
    • Serveur central unique
    • Check-out, check-in
    • Risque de conflits
  • Décentralisés: Git, Mercurial
    • Copie locale complète
    • Branches, merges, commits locaux
    • Facilité de collaboration

Workflows de développement

  • Définition: organisation des branches et des cycles de vie du code source
  • Objectifs: Isoler les développements, faciliter les tests, garantir la stabilité
  • Exemples:
    • GitFlow: Branches principales (main, develop) et branches de support (feature, release, hotfix)
    • Feature Flow: Branches principales (main) et branches de fonctionnalités temporaires
    • Forking Workflow: Forks et pull requests pour contribuer à un projet

Intégration continue (CI) et livraison continue (CD)

  • Intégration continue (CI)
    • Build et tests automatiques à chaque commit
    • Détection rapide des problèmes d’intégration
    • Validation de la qualité du code (linting, tests unitaires)
  • Livraison continue
    • Package automatique en artefacts déployables
    • Tests d’intégration et système automatisés
    • Validation par les équipes QA

Déploiement continu (CD)

  • Mise en production automatique après validation CI
  • Déploiement progressif (canary, blue-green)
  • Surveillance et rollback automatique si problème

Réutilisation