###### tags: `Master`
## Exercices
### Série 1
#### Exercice 1
1. On a de l'incertitude
2. Le coût du changement
3. Repousser la décision le plus tard possible (prendre des décisions tout de suite c'est de la merde)
4. Essayer de faire que la décision ait le moins d'influence possible, la rendre la moins importante
5. On fait du découplage (avec des patterns)

#### Exercice 2


### Série 2
### SOLID
#### Exerice 1
- Liskov Substitution Principle
#### Exerice 2
- Dependency Inversion Principle
#### Exercice 3
- Single Responsibility Principle
#### Exercice 4
- Service de log
- Elle accède au fichier
- Elle a un service de cache
- Elle orchestre les opérations (impose l'ordre d'exécution)

#### Exercice 1

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this

                "d (1.0)"->{"a (0.33)" "e (0.66)" "f (0.33)"}
                "e (0.66)"->{"c (0.5)" "a (0.33)"}
                "a (0.33)"->"c (0.5)"
                "c (0.5)"->{"b (0.0)", "f (0.33)"}
                "f (0.33)"->"b (0.0)"
                {rank=same;"a (0.33)" "c (0.5)" "f (0.33)"}  // Put them on the same level
}

* Pas de cycle
* Pas stable car l'instabilité de C est plus grand que l'instabilité de A (celui sur quoi il dépend).
#### Exercice 2

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this
    p1 -> {p2}
    p2 -> {p3 p4}
    p3 -> {p4}
                
                {rank=same;}  // Put them on the same level
}

![Uploading file..._bvd7825kp]()

| Package | CC | AC | Ca | Ce | A | I | D |
| -- | -- | -- | -- | -- | ---- | --- | --- |
| p1 | 1 | 0 | 0 | 1 | 0.0 | 1.0 | 1.0 |
| p2 | 1 | 0 | 1 | 2 | 0.0 | 0.66 | 0.33|
| p3 | 1 | 2 | 1 | 1 | 0.66 | 0.33 | 0.0 |
| p4 | 0 | 3 | 2 | 0 | 1.0 | 0.0 | 0.0 |

# Génie logiciel : méthodes de développement et architecture

La SE ne concerne pas seulement la programmation. Il faut résoudre le bon problème et proposer une bonne interface.

Il faut établir la communication, réspecter des delais, établir des budgets, organiser des meetings.

## Definition SE:
- Production: produire un logiciel que l'on veut faire trouner dans un environnement de production pendant des années. Produit(software) mis en production.
- Qualité: Doit être évaluer aussi objectivement possible en se basant sur des standards.

## Stakeholder:
Toute personne qui peut ou est affecté par le projet.

## The Diamo view of SE
- Describe
- Implement
- Assess
- Manage
- Operate

### Describe :A
On doit savoir ce qu'on veut faire. Qu'elles sont le propriétés necessaire de la solution.
- outils: Faire des use case

### Implement
Vue restrictive de la programation
- Design
- Architecture

### Assess
Evaluation du produit
- Design
- Documentation
- Manuel
- Maintenabilité
- Doc du Design

Décider comment on va évaluer. Definir des métriques

### Manage
Gestion du projet. ordonnancement des taches pour respecter les delais, être capable de gerer les changements de communication, capable de gérer les équipes.

### Operate
Deployer l'application. Cela peut être un phase majeur. Dans l'esprit de ..., operate contient la maintenance. Sinon il faudrait ajouter cette phase. C'est mieux d'avoir une tache séparer pour ca.

**On va se concentrer sur la software Architecture**

## Aspect organisationnel
L'architecture d'un software est relié à l'equipe qui l'a fait.

Quand les equipes sont proches les unes des autres les equipes on plus tendances à créer qqch de monolithique. Si le projet est open source on a plus qqch de modulaire.

On cherche à avoir des logiciels avec un faible couplage (on aime pas les variables globales). La POO facilite le couplage faible. au profit de la perforance mais la performance n'est pas critique.

## Resultat de la loi de Conway

On doit d'abords refelchir à l'architecture avant de créer des equipes.

# Architecture

- est un processus
- est une profession
- fournit un résultat

L'architecture c'est un plan

- donne une overview
- facilite la comprehension
- permet la communication
- augemente la flexibilité

Architecture 3-Tier
1. Presentation
2. Business logic
3. Persistence

Software Architecture
- process: design
- product: voir slide
- means: voir slide

- structre: diagramme de classe
- comportement: diagramme de séquence
- interaction: diagramme de communication
- non-fonctionnel: décrit avec des mots

Fonctionnel => UML

Décrire le systeme logiciel en le séparant en composants. Il faut montrer les relations entre les composants pour avoir différente vues.

L'architecture founrit des documents
- Diagramme UML

### 4+1 Architectural Views

Décrit l'architecture d'un logiciel basé sur plusieurs vue.

Exemple: la carte. en fonction de ce qu'on veut faire, on choisit une (view) de carte différente.

- logical view
- par fonctionnalité fourni au end-user
- Class/Communication/Sequence diagram UML
- development view (implementation view)
- vue du développeur
- Composant/Package diagram UML
- Process view
- Comportement du système
- Diagramme d'activité
- Diagramme de séquence (petite partie du logicile)
- Physical view
- vue physique du système
- Diagramme physique
- Scenarios
- On décris des sénarios en utilisant des use case
- Diagramme de Use case

Il faut différentes vues pour présenter différent aspect du système.

Les différents stakeholders ont besoin de vues différentes.

Les dessins à la main(non formel) sont biens au débuts mais il faut essayer de les formaliser en UML.

### Overall goal

On devrait design notre systems de la sorte à:
- les composents peuvent être echanger avec des nouveaux(maintenabilité)
- Felxiblité
- reutilisabilité
- clair et compréhensible
- faisable et atteignable
- fonctionnel :a:

### Role de l'architecte logiciel
- garantir que l'on suit les requirements
- Design et construit
- Coach et consult les dev et les stakeholder
- demontre la faisabilité

### Résumé
- Simplicité
- abstraction
- ...

## Article
Evolution de la pensée de l'architecture logiciel appliqué au dev logiciel. On en est eu dernier stade (popularisation). C'est plus un domaine de recherche, on affine et on crée des outils.

Aujourd'hui on veut pas seulement des logiciels qui marchent mais aussi qui respecte une bonne architecture.

# Component-based design

decomposition du design en composent logique ou fonctionel qui representent une interface de communication.

donne un abstraction supérieur et permet un compréhension globale

## Component
- Modulaire
- portable
- remplacable
- reutilisable

- Object-oriented view
Un set d'une ou plusieurs classes qui coopère
- pas le temps de noté
- Porcess view
- le système est contruit sur des composents qui existe deja
- UI
- Fait des calculs
- composents invisible
- BDD (par exemple)

### Interface (java)
Un apsect majeur d'un bon logiciel basé component est dans l'interface

Derrière les interfaces:
- Algorithmie
- Beaucoup de problèmes n'emploient pas des algorithmes compliqués mais dépendent de la structure.

type d'interface:
- Data-service
- data: accède aux données (get, set) dans bdd p.e
- service: fait qqch sur les données (un sérvice sur les données)
- Interface simple-multiple
- accès à l'interface
- stateful-stateless
- etat interne ou non
- Minimal-Complete

## Couplage
Quelle classe est couplée avec quelle classe. Un sytstème fortement couplé est très dur à étendre et a maintenir

## Cohésion
Combien un element du système estr cohérent dans ce qu'il fait. UN module doit s'occuper d'une chose bien précise.

Un un composent avec une faible cohésion est difficil à comprendre et a maintenir.

:a: **il faut un faible couplage et une bonne cohésion.**

## SOLID
5 principes pour faire un code plus propre et plus simple à gérer

* Single Responsibility Principle
* Chaque composant doit avoir qu'une seule responsabilité et que cette responsabilité doit être entièrement encapsulé dans cette classe
* Une classe ne devrait avoir qu'une seule raison de changer
* Open-Closed Principle
* Pouvoir étendre les fonctionnalités d'une classe sans modifier son comportement
* L'héritage
* Open for extension, closed for modification
* Pattern Adapter
* Liskov Substitution Principle
* Une sous-classe doit pouvoir être substitué par les classes dont elle est dérivée
* Interface Segregation Principle
* Un client ne doit pas implémenter des interfaces dont il n'a pas besoin (plusieurs petites interfaces au lieu d'une seule grande)
* Dependency Inversion Principle
* Les composants de haut niveau dépendent des composants bas niveau
* Résumé
* Facile à tester, maintenir, réutiliser, plus évolutif
* Augmente le niveau d'abstraction (interface, classe abstraite)
* IS-A relationship est à propos du comportement et non de l'implémentation

## Package Design
* Acyclic-Dependency Principle
* Retirer les boucles
* Stability (Instability)
* Un package est stable si beaucoup de package dépendent de lui
* Lié à la quantité de travail nécessaire pour effectuer un changement
* Metric :
* Afferent Coupling : Nombre de package qui dépendent de moi. Plus on dépend de moi plus j'ai de répsonsabilités
* Efferent Couplings : Nombre de package dont les classes dans le package dépendent (Independence). Je dépends des autres je suis pas indépendent
* Instabilité (range[0, 1])
* $I = \dfrac{C_e}{C_a + C_e}$
* I = 1
* Ca = 0
* Ce >0
* c'est instable, irresponsable, ... slide (14)
* Stable Dependency Principle
* L'instabilité d'un package doit être plus grand que l'instabilité des package dont on dépend

## Design by Contract
### Principe
Un composant définit
* Les pré-conditions des fonctions
* Que le client doit fournir
* Nécessaire pour le client
* Post condition des fonctions
* Ce qu'un composant promet d'établir
* Assuré par le client

### Contrat
Définit
* Les obligations des deux parties et leurs bénéfices.
* Ce qui arrive si les obligations ne sont pas remplis

### Non-redundancy principle
Le corps d'une routine ne doit sous aucune circonstance tester la pré-condition de la routine

### Contrats et héritage
* Le principe de substitution de Liskov s'applique
* Un sous-type peut être utilisé à la place du type de base
* Pré conditions plus faible : si on remplace qqch qui a besoin de moins ça va
* Post conditions plus forte : si on remplace qqch par qqch qui fait mieux, c'est ok, pas l'inverse

### 6 principes du DbC
* Séparer les requêtes des commandes
* Soit ça modifie, soit ça fourni une information, mais pas les 2
* Séparer les requêtes de bases des requêtes dérivés
* Pour toutes les requêtes dérivés, avoir une post condition qui spécifie le résultat qui doit être retourné en fonction d'une ou plusieurs requêtes de bases
* count=0 sur un count d'une liste vide
* Pour chaque commande, écrire une postcondition qui spécifie la valeur de chaque requête de base
* Pour chaque requête ou commande, une commande décide d'une précondition adéquate
* Écrire des invariants pour définir des propriétés qui ne changent pas
* Forme de documentation de la classe en fonction de ce qu'elle garantie
* count_non_negative : 0 <= count

### Pourquoi DbC est difficile ?
* Pas de langage autre qu'Eiffel
* Pas utilisé systématiquement

### Bénéfices
* Outil permettant de spécifier les composants d'une manière claire
* Défini clairement les responsabilités entre un client et le fournisseur

### Tests unitaires
Penser en manière de contrat aide à définir les tests unitaires :
* Qu'est-ce qui est requis du caller
* Qu'est-ce qui doit être implémenté

## Software Architecture Documentation and Analysis
### Pourquoi c'est important de documenter
* Évite de refaire ce qu'on a déjà fait
* Permet de justifier pourquoi une architecture est bonne (on a une métrique)

### 7 règles pour une bonne documentation
* Écrire la documentation du point de vue du lecteur
* Éviter des répétitions inutiles
* Éviter l'ambiguité
* Utiliser des standards (permet d'éviter les ambiguités)
* Garder la documentation à jour
* La documentation doit être adapté sur quoi elle a été prévue

### C'est quoi une vue ?
* Représentation de l'ensemble des éléments du système avec la relation entre eux

### Principales vue
* Context Views
* Illustre le système et son environnement
* Component Views
* Illustre la stricture interne du système
* Behavioral Views
* Illustre le comportement temporel du système
* Deployment Views
* Illustre l'environnement physique du système

### Data Flow diagram level 0
On se concentre sur les flux d'informations (système central <-> composants)

### Component Views
* Montre les ingredients d'un système
* Important pour représenter les interfaces

### Behavioral Views
* Montre l'interaction entre les vues (Use Case)
* UML Use case: scenario que fournit un service, input du système. Statique : pas de temps
* brief format: que quelque phrases
* UML Activity diagram : décrit un comportement, plutot grosse partie du système voir le système complet.
* UML : Sequence diagram : Comment on va faire, on a des instances d'objet
* UML : Commnuication Diagram : prend le temps en compte, on voit les communications entre composant
* UML : Diagramme d'état de transition (State chart)

Le modèle doit être indépendant de l'implémentation. Mais maintenant on utilise souvent des framework qui eux imposent une architecture. Donc c'est pratique de réfléchir quelle plateforme on va utiliser.

## Software evolution and aging

- Waterfall
- Agile

### Lehman's Laws of evolution
* System-X
* Statistiques pour regarder dans la réalité comment se comportait les logiciels
* Le nombre de module qu'il faut changer pour chaque release indique la complexité du système

Lois :
* Un système doit toujours s'adapter pour satisfaire les besoins
* La complexité d'un système ne fait que de croître

Un programme doit évoluer sinon il devient inutile. Si on ne s'adapte pas, le programme devient de plus en plus complexe. Si on ne prend pas des actions spécifiques, la qualité se dégrade.

### Différents type de systèmes de programme
* S-Programs
* Programme qui peut être complétement spécifié
* Le problème à résoudre est completement définit
* Ex : algorithme de trie
* P-Programs
* Programme qui peut être complètement spécifié mais qui fait une approximation de la vie réelle
* Le problème à résoudre ne peut pas être completement spécifié
* AI pour les échecs
* E-Programs
* Programme qui mécanise une activité humaine ou sociétal
* ERP

### Ce qui fait vieillir un logiciel
* Manque de mouvement
* C'est parce que plus personne n'a touché le logiciel qu'il vieillit
* Ignorant surgery
* Changer le software peut causer son vieillissement (si les gens qui modifient le programme ne sont pas conscient du concept initial)

### Les coûts du vieilissement d'un logiciel
* C'est dur de rester sur le marché avec un vieux logiciel
* Les performances se dégradent (mais c'est souvent compensé par l'amélioration du hardware)
* Décroit la fiabilité du système (une erreur corrigé engendre souvent une nouvelle erreur)

### Comment réduire le coût
* Médecine préventive
* Faire un design de qualité
* Garder des traces (documentation)
* Faire des reviews par les gens qui sont concerné par la maintenance
* Software geriartics
* Stopper la détérioration
* Documentation rétroactive
* Amputation des parties du logiciel foireux

### Barrière empêchant la progression
* Software crisis
* Prévient l'analyse profonde nécessaire à soigner une maladie chronique
* Getting it to run
* Provoque un vieillissement de forcer le programme à tourner

### Conclusion
* Le vieillissement est inévitable
* Le meilleur moyen est designer un programme pour l'adapter au changement
* La documentation doit être fait avec une notation formelle

### Maintenance Software
* Prévient le vieilissement en général, mais peut le causer

#### Définition
* Modification d'un logiciel pour le faire évoluer
* Correction de fautes
* Augmenter les performance
* Adapter le produit à son environnement modifié

#### Maintenance
- Corrective
- Preventive
- Adaptative
- Perfective

### Dette technique
* Si on fait de la merde actuellement, on s'endette dans le future (ça va coûter plus cher de modifier à l'avenir)

### Terminologies
* Forward Engineering
* Déplacement d'un haut niveau d'abstraction vers l'implémentation physique
* Exemple : UML -> Code
* Reverse Engineering
* On part de qqch qui existe et on sort un haut niveau d'abstraction
* Exemple : Code -> UML
* Reengineering
* 0) Analyse des requirements
* 1) Code -> On génère le modèle
* 2) Détection des problème
* 3) Résolution des problèmes
* 4) Recréation du programme

## Architectural Styles & Patterns
### Architectural Styles
Cela définit une famille de système en terme de pattern d'organisation structurelle. Plus spécifiquement c'est un ensemble de composants et de connecteurs ainsi que des contraintes et comment ils sont combinés.

### Common Architectural Styles
* Dataflow system
* Batch sequentiel
* Pipe et filtres
* Call-and-return
* Système orienté objet
* Main, subroutine programs
* Independent components
* Processus de communication
* Systèmes évènementiels
* Virtual machines
* Interpreters
* Data centered
* Databases
* Hypertext systems

### Dataflow architecture
**But principal** : Réutilisation et modifiabilité
* Ne possède pas de program counter
* L'exécution est déterminé par la disponibilité des arguments d'entrés
* L'ordre d'exécution est non déterministe
* Exemple
* Pipe and filters

### Call-and-return
**But principal** : Modifiabilité et solvabilité
* Style d'architecture dominant ces 30 dernières années
* Différents sous-styles
* Programme principale et sous-routines
* Appel de procédure à distance
* Orienté objet


### Independant components
**But principal** : Modifiabilité et découplage
* Processus indépendant qui communiquent par messages
* Les messages peuvent passer par
* Des participants nommés (Communicating Processes style)
* Des participants non nommés avec le paradigm publish/subscribe (Event Style)

### Virtual Machine Architecture
**But principal** Portabilité
* Simule les fonctionnalités non natives d'un software ou hardware
* Simulation de platformes n'ayant pas encore été implémentés (nouveau hardware)
* Simulation de mode désastre (simulateur d'avion)

### Data Centered Architecture
**But principal** : intégrabilité des données, évolutivité
* Système dont l'accès et la mise à jour de données à large accès se fait souvent
* Données centralisés communiquant avec des clients
* Deux sous-types
* Repository (figure)
* Blackboard
* Modifications sont envoyés aux abonnés quand des données changent


### Design pattern !? Architectural patterns
* Un design pattern fourni un schéma pour raffiner le sous-système ou les composants d'un logiciel. Il décrit la structure revenant fréquemment pour résoudre un problème particulier.
* Un Architectural Pattern définit la structure fondamental d'un logiciel. Définit un set de sous-systèmes et leurs responsabilités.

### Architectural pattern
Définit la relation entre
* Un contexte
* Une situation courante qui cause un problème
* Un problème
* Un problème généralisé
* Une solution
* Une architecture abstraite permettant de résoudre le problème

### Catégories de pattern architecturaux
Sont catégorisés par rapport aux types d'éléments qu'ils représentent
* Module patterns
* Layered Pattern
* Component-and-connector patterns
* MVC pattern
* Allocation patterns
* Map-reduce pattern

### Layered Pattern
* Contexte
* Besoin de développer et faire évoluer des potions du systèmes de manière indépendante
* Problème
* Le logiciel a besoin d'être segmenté d'une façon où les modules peuvent être développer et évoluer séparément avec peut d'interaction et supporter la portabilité, modifiabilité et réusabilité.
* Solution
* Diviser le logiciel en différentes unités appelées layers. Chaque layer est un groupement de modules qui offrent des services. Les relations sont unidirectionnels


#### Solution
* Élément : Layer
* La description d'un layer défini ce qu'une la couche contient comme module et les services qu'elle fourni
* Relations : allowed-to-use
* Spécialisation de la relation depend-on
* Contraintes
* Chaque partie du logiciel est alloué à une seule couche
* Il y a au moins 2 layers
* Les relations allowed-to-use ne doivent pas être circulaire

#### Notation
Stack-of-boxes

La relation allowed-to-use est défini de haut en bas

Une couche n'est PAS autorisé à utiliser les couches au dessus d'elles. Un module utilise un autre module, mais l'autre s'en fout de recevoir une réponse

#### Avantages
* Réutilisation des couches
* Les dépendances sont locales
* Échangeabilité : l'implémentation d'une couche peut être remplacé par une autre sémantiquement équivalente

#### Désavantages
* Peu efficace (transfère de données entre layers)
* Difficulté de trouver la bonne granularité
* L'ajout de couche ajoute des coûts et de la complexité

### Pipe-and-Filter Pattern
* Contexte :
* Transformer un stream de données d'input en output.
* Problème :
* Ce genre de système doit être décomposé en composants réutilisable, simple et faiblement couplé
* Solution :
* Les données arrivent en entrée, sont transformé puis passé à la sortie au prochain filtre

#### Solution
* Element : Filter
* Composant qui transforme les données lues en entrées en données écrites en sortie
* Ils peuvent être exécuté de manière concurrente
* Relations : Attachment
* Associe le filtre de sortie au input des pipes et vice versa
* Contraintes
* Les pipes connectent les sorties aux entrées
* Les filtres connectées doivent se mettrent d'accord sur le type de données envoyés

#### Structure

#### Exemples
Unix shell programs (cat file1 | sort | grep keyword)
JEE Servlet Filter

#### Avantages
* Supporte la réutilisation, parallelisation et raisonnement simplifié du comportement global
* Convient bien aux calculs scientifique qui doivent process de grande quantité de données

#### Désavantages
* Pas bien pour un système intéractif
* Avoir un grand nombre de filtre indépendant ajoute une quantité d'overhead de calcul
* Ne convient pas aux programme ayant un grand temps de calcul

### Publisher - Subscriber
* Context :
* Producteurs et consommateurs indépendant doivent intéragir. Le nombre et la nature de ceux là ne sont pas déterminés à l'avance
* Problème :
* Comment créer un mécanisme d'intégration qui puisse transférer des messages entre les producteurs et les consommateurs sans qu'ils ne soient au courant de l'identité de chacun ?
* Solution :
* Composant intéragisant via des messages non annoncés ou des évènements. Les composants peuvent s'abonner à des évènements et chaque évènement publiés est distribué à tous les abonnés

#### Solution
* Élément :
* Au moins un poort publish ou un port subscribe
* Relations : Attachment
* Associe un composant publish-subscribe connecteur en indiquant quel composants annonce les évènements et quel composant est enregistré pour recevoir ces évènements
* Contraintes :
* Restriction sur quel composant peut écouter quel évent ou combien de connecteur peuvent exister dans un système.

#### Exemples
* Interfaces graphiques
* Applications MVC
* Systèmes ERP (Enterprise resource planning)
* Mailing lists
* Social networks

#### Structure

#### Avantages
* Découplage des subscribers des publishers
* Les publishers et subscribers peuvent venir et partir
* Adapté pour l'IoT (MQTT)

#### Désavantages
* Combien de temps un service d'évènement doit garder un évènement ?
* Comment un subscriber peut s'assurer de l'authenticité d'un évènement ?
* Augmente la latence
* Moins de contrôle sur l'ordonnancement des messages et l'aboutissement des messages n'est pas garantie

### Model-View-Controller
* Contexte :
* Dans une application interactive, l'UI est la partie la plus modifiée. C'est important de garder les modifications de l'UI séparée du reste du système
* Problème :
* Comment garder l'UI responsive aux inputs utilisateurs tout en la séparant des fonctionnalité de l'application ?
* Comment créer et maintenir différentes vue de l'UI quand les données changent ?
* Solution :
* Séparation en 3 composants :
* Model qui contient les données de l'application
* View qui affiche une portion des données et intéragit avec l'utilisateur
* Controller qui sert d'intermédiaire entre la vue et le modèle et gère les notifications de changement d'état

#### Exemple

#### Solution
* Éléments :
* Le modèle est une représentation de l'état et des données de l'application
* La vue est l'interface utilisateur qui produit une représentation du modèle et permet les inputs
* Le contrôleur gère l'interaction entre le modèle et la vue et gère les actions utilisateurs qui changent le modèle ou la vue
* Relations :
* Les changements d'états entre le modèle, la vue et le contrôleur se font au moyen de notifications
* Contrainte :
* Il doit y avoir au moins une instance de la vue, modèle et contrôleur
* Le modèle ne doit pas interagir directement avec le contrôleur

#### Notation
Les composants MVC sont connectés au moyen de notification (events ou callbacks)
* Ces notifications contiennent la modification de l'état
* Un changement dans le modèle doit être communiqué à la vue
* Un event externe doit être communiqué au contrôleur qui doit à son tour update la vue ou le modèle
* Les notifications peuvent être push ou pull


#### Comportement : Gestion de l'input utilisateur

#### Comportement : Initialisation

#### Observer Pattern
Souvent utilisé pour implémenter une architecture MVC ou Publisher-Subscriber

#### Observer et MVC

#### Avantages
* Plusieurs vues pour le même modèle
* Vues synchronisées
* Vues et contrôleur "pluggable"
* Échange de "look and feel"
* Potentiel pour un Framework

#### Désavantages
* La complexité n'est pas forcément rentable pour des UI simples
* Couplage fort entre la vue et le contrôleur et entre vue / contrôleur et modèle

### Service-Oriented Architecture (SOA)
* Destiné à supporter les entreprises sur internet. Une entreprise A pourrait obtenir des services d'un vendeur B qui lui pourrait obtenir des services d'un vendeur C.
* Les services sont souvent décentralisés et doivent gérer les problèmes de réseaux
* Chaque service a une interface bien définie qui permet d'être publié ou découverte

Fuck la suite, trop chiant

## Architecture & Design Patterns for Web Development

Slide 15 : Non, il y a un intermédiaire (c'est plutôt du pub/sub, on s'inscrit au channel alors que l'observer communique directement (slide 16))

### Dérivés du MVC
#### MVP
Le contrôleur est remplacé par le présentateur. Le présentateur écoute les évènement venant de la vue et du modèle. Un présentateur ne gère qu'une seule vue. Le présentateur utilise l'observer pattern.

En MVP la vue ne communique pas directement avec le modèle.

Bénéfice :
* Comme un présentateur ne gère qu'une seule vue, les tests sont plus découplés et plus simple
* Contrairement au contrôleur qui peut devenir gros, le présentateur est assez simple

Par rapport au contrôleur, le présentateur va préparer les données, par exemple faire la conversion des francs en euro alors que le contrôleur lui ne s'occupe pas de ça.

#### MVVM (Model View ViewModel)
Pas de lien direct entre le modèle et la vue.

Différence avec MVP :
* Un ViewModel gère plusieurs vues
* Chaque vue va se connecter aux propriétés de la ViewModel

JavaFX utilise le MVVM.

Pas besoin de gérer soit même les refresh etc. On fait moins de code.

## MVC

On du mal a voir d'où vient l'erreur

MVC n'est pas scalable. C'est pour ça que Facebook a créé FLUX.
La solution : sortir les composants dans une classe globale.

Bénéfice de FLUX :
* Améliore la consistence des données
* Meilleur maintenance et plus facile de détecter les bugs
* Tests unitaires

Redux -> pattern FLUX dans REACT

:warning: EXA :warning: :

FLUX : unidirectionel data flow

### Vuex

- Integré à Vue.js

### Redux
* High-Order Components
* Pattern dans REACT
* On prend un composant et on en génère un nouveau
* mapStateToProps pour convertir un état en propriété pour l'utiliser dans le code
* Modification
* On prend l'ancien état et on génère un nouvel état (parce que c'est immuable)

### Twelve-Factor Applications
Bonnes pratiques pour des architectures d'applications cloud native

#### 1) Codebase
Une seule codebase tracké avec Git, plusieurs déploiement (production, staging, developer 1...)

#### 2) Dependencies
Déclarer explicitement et isoler les dépendances.
Permet de simplifier la mise en place de l'application

#### 3) Config
Stocker la config dans l'environnement (lien vers la BDD, credentials pour les services externes)

#### 4) Backing Services
Un backing service est un service que l'app utilise au travers du réseau pour son utilisation normal (database, messages...).
Pas de différence entre un service local et externe. Une ressource peut être attaché / détaché sans changer le code.

#### 5) Build, release, run
Séparation distincte en Build, Release et Run

#### 6) Processes
Les processus sont sans état et ne partagent rien

#### 7) Port Binding
Exportation de services via le port binding (écoute sur un port et répond en HTTP sur ce port). Une app' peut devenir le backing service d'une autre app.

#### 8) Concurrency
Gestion de différents workload en assignant chaque type de travail à un process type (HTTP requests géré par un web process, tâche longue géré par un worker process)

#### 9) Disposability
Démarrage rapide et shutdown clean

#### 10) Dev / Prod parity
Avoir un environnement similaire entre le développement et la production.
* Éviter le time gap
* Ne pas déployé du code écrit il y a qq minutes / heures
* Éviter le personnel gap
* Le dev qui écrit du code est impliqué dans son déploiement
* Éviter le tool gap
* Avoir les mêmes outils en dev qu'en prod

#### 11) Logs
Traiter les logs comme des streams d'évènements

#### 12) Admin processes
Les processus administratifs / de managements (database migrations) sont traité comme processus unique dans un environnement similaire

Avantage slide 41 : encapsulation


## Stub vs Fake vs Mocks
* Stub : retourne juste une valeur
* Fake : similaire à l'implémentation réelle, mais fausse (hashmap au lieu de BDD)
* Mocks : vérifie une interaction (s'assure que l'appel se produise comme il faut)

* The Product Backlog
* Sprint
* Reference Stories
* Prioritisation
* Everyday
* Sprint Review


| Redux | Vuex |
| -------- | -------- |
| Immutable | Mutable |
| Reducer | Mutation |
| Pas spécifique à React (besoin d'import) | Integré à VueJS |
| Utilisation de High Order Components | Getter / setters |