SlideShare une entreprise Scribd logo
1  sur  126
Architecture Logicielle
Gaëtan ELEOUET
eleouet.esiea@gmail.com
Architecture et design ?
Du système à la ligne de code
Software is not limited by physics, like buildings are. It is limited by
imagination, by design, by organization. In short, it is limited by
properties of people, not by properties of the world. “We have met
the enemy, and he is us.”
Martin Fowler - Who Needs an Architect?
Gaëtan
• Ingénieur ENSEEIHT
• 10+ années d’expériences
• Expert Java
• Pratiques du développement
• Concours d’IA
• 2 enfants
• Menuiserie
• Cuisine
• Photographie
• …
Meritis
• Cabinet de conseil en technologies
de l’information
• 350 personnes
• Technique
• Métier
• Gestion de projets
• Opérationnels
• http://www.meritis.fr
Sommaire
• Qu’est ce qu’est l’architecture ?
• Atelier conception document
• Architecture micro-service
• Atelier micro-service
Qu’est ce qu’est l’architecture
• Design ?
• Organisation ?
• Histoire ?
Introduction
A ne pas faire
chez soi ->
Définition
• Comment un système d’information doit être conçu
• De manière symbolique et schématique
Construction d’une application
Besoin
fonctionnel
Algorithme
Architecture
Construction d’une application
Besoin
fonctionnel
Algorithme
Architecture
Pourquoi ? Quoi ?
Comment ?
Métier d’architecte
• Documents d’architecture
• Méthodologies
• Outils de développement
• Proof of concepts
• Veille technologique
Document d’architecture
• Représente les interactions
• Les différents éléments
• Exemple Pinot (OLAP - LinkedIn)
Document d’architecture
• Exemple LMAX :
• Détaillé au niveau des cœurs
du processeur
• Cache friendly collection
• Le document sert à
communiquer la structure qui
satisfait les contraintes
exprimées du système
Méthodologie
• Equipe
• One team
• Pizza team
• TDD
• BDD
• Qualité
…
• Agile
• Scrum
• Kanban
• Etc…
• Contractuelle
• Cycle en V
• Intégration continue
• Continuous delivery
Outils de développement
• Environnement de développement
• Langage
• Gestion de sources
• Environnement de build
• Supervision de la qualité
• Suivi de code review
• Matériel
• Communiquer les bonnes pratiques
Proof of concepts
• Maturité des technologies
• Adaptabilité aux besoins
• Réécriture d’existant
• Documentation
• Minimum Viable Product ?
• Simple Complete Lovable ?
• Communiquer les concepts à étudier
React.js Angular Polymer…
Veille technologique
• Suivi de l’existant et des nouvelles versions
• Découverte des nouveautés
• Suivi des technologies abandonnées
• Production ?
• Communiquer avec les différentes équipes
Architecture Logiciel
• Motivations
• Historique
• Définitions
• Exemples
• L’architecture est intégrée dans le
travail de tous les développeurs
L’art de construire des logiciels
• Choix des langages,
technologies, méthodologies
• Structure résultante d’une
application
L’architecture n’est
pas un art
Motivations
• Réduction des coûts
• Augmentation de la qualité
Un logiciel est fait pour durer dans le temps
Projet
Qualité
Coût Délai
Motivations
• Evolution de l’application
• Besoins
• Technologies
• Réglementation
Qualité
• Maintenabilité
• Portabilité
• Fiabilité
• Efficacité
• Facilité d’utilisation
Critères de qualité logicielle
• Interopérabilité
• Portabilité
• Compatibilité
• Validité
• Vérifiabilité
• Intégrité
• Fiabilité
• Maintenabilité
• Réutilisabilité
• Extensibilité
• Efficacité
• Autonomie
• Transparence
• Composabilité
• Simplicité
Historique
• Programmation structurée
• Langage procédural
• Architecture en flux d’instructions
• Programmation par composants
• Architecture statique
• Architecture dynamique
• Programmation objets
• Architecture programme
• Architecture données
• Programmation fonctionnelle
• Architecture hexagonale
• Architecture serverless
• Programmation agents
• Architecture distribuée
Complexité
Historique
• Des besoins de plus en plus complexes
• Des équipes de plus en plus grandes
• Des quantités de données plus importantes
• Mieux comprendre le système
• Travailler en isolation sur différentes parties
• Extensions du système
• Réutilisabilité
C’est ici le rôle de
l’architecture
logicielle
Pourquoi
dans une slide
historique ?
Architecture logicielle (Garlan 2000)
• Compréhension : vue de haut niveau, contraintes
• Réutilisation : identification des « parties » communes
• Construction : plan de développement
• Evolution : points d’extensions
• Analyse : cohérence, conformité, dépendances
• Gestion : dépendances, impact des délais,
ordonnancement
Architecture
Spécifications
Code
Définition(s)
• Description d’un système complexe
• Architecture = éléments + formes + motivations (Perry et Wolf)
• La structuration d’un système informatique, matériel et logiciel, en
termes de composants et d’organisation de ses fonctions ainsi que
leur relations
Choix et motivations
• Technologies
• Produits
• Serveurs
• Nature du projet
• Délais
• Coûts
• Compétences disponibles
• …
Description d’une architecture : 4 + 1
Scénario
Logique
Processus
Implémentation
Physique
Philippe Kruchten
Vue logique vers vue physique
• Vue logique
• Principaux composants
• Maximiser la cohésion
• Minimiser le couplage
• Vue Physique
• Déploiement physique des différents services
• Ressources
• Contraintes
Temps
Abstraction
4 + 1 : Vue logique
• Système décomposé en sous-systèmes
• UML : Diagramme de package
4 + 1 : Vue implémentation
• Implémentation du système en termes de composants et de
connecteurs
• UML : Diagramme de composants
4 + 1 : Vue processus
• Aspect dynamique du système
• Concurrence, performance, scalabilité
• UML : diagrammes d’activité
4 + 1 : Vue physique
• Topologie du système et connections physique
• UML : diagramme de déploiement
4 + 1 : Scénario
• Séquences d’interactions
• Illustre et valide l’architecture
• Point de départ
• UML : Use cases
• Agile : Users stories
Composant
• Unité autonome d’un système
• Peut-être remplacé ou réutilisé
• Elément d’implémentation
• Représente un objet ou un sous-système
• Différent d’une instance
• Séparation des préoccupations (SoC)
Composant
• Interfaces offertes
• Interfaces requise
• Nom
• UML Composant
Interface offerte
Interface requise
Diagramme de déploiement
• Ressources utilisées
• Matériel
• Programme utilisé
• Connexions entre les nœuds
• Protocole
• Contraintes
• Artefacts ( application, base de données, etc…)
Déploiement
• Ressources
• Contraintes
Analyse
Serveur 1
Proxy
Analyse
Serveur 2
Bus
Persistance
Serveur 3
BDDBDDhost:port
http:rest
https:rest
Style architectural
• Définit composants, connecteurs, contraintes
• Patron avec un vocabulaire commun
• Lien avec les design patterns en programmation
Pipeline
• Traitement et transformation de données
• Séquentiel ou pipeline
• Unidirectionnel
• Tampon, points de synchronisation
Filtre
Canal
Synchro
Centrée données
• Entrepôt de données centralisé
• Repository, par requête
• Blackboard, par notification
• Intégrité des données par design
Client Client
Référentiel
BDD
EventSourcing
• Etat initial + suite évènements = état actuel
• On sauvegarde l’état initial
• On sauvegarde la suite d’évènements
E E E E …
Event Store
Modèle
Facade
CQRS - Command Query Responsibility
Segregation
• Séparer la lecture de données QUERY
• Séparer l’écriture COMMAND
Query
Command
Client - Serveur
• Les clients connaissent les serveurs
• Les serveurs ne connaissent pas les clients
• Séparation des tâches
Client
Serveur
requête réponse
Client Serveur
requête
réponse
Distribuée
• Chaque nœud est à la fois client et serveur
• P2P
• Paradigme de programmation
MVC – Modèle Vue Contrôleur
• Modèle contient les données
• Vue présente les données
• Contrôleur traite les actions
Vue
Modèle Contrôleur
MVP – Modèle Vue Présentation
• Pas d’interaction entre la vue et le
modèle
• La présentation organise les données
à afficher dans la vue Vue
Modèle Présentation
3 - Tiers
• Présentation
• Traitement métier
• Persistance des données
Présentation
Application
Persistance
http
query
N - Tiers
• Empilement de couches
• Chaque couche a sa propre responsabilité et utilise la couche
immédiatement en dessous
Présentation
Contrôleur
Service
Domaine
Persistance
Sécurité
Technique
Couche - Présentation
• Client Lourd
• Poste client
• Client Léger
• Navigateur web
• Ecrans générés sur le serveur
• Client Smart
• Compromis
• Single Page Application …
Couche - Contrôleur
• Contrôle la cinématique
• Appels de service
• Erreurs et exceptions
• Sessions ?
• Autorisations ?
Couche - Service
• Implémentation de la logique métier
• Sécurité applicative
• Transactions
• Intégrité des transactions
• Appels à la couche domaine
Couche - Domaine
• Règles métier statiques
• Sans états
• Accès aux objets métiers
• Via la couche persistance
• Domaine commun ?
Couche - Persistance
• Opérations CRUD
• Abstraction des DAO et ORM
• Vision objet du modèle
• Supporte les transactions de la couche domaine
Couche – Sécurité
• Authentification
• Autorisations
• Intégrité
• Sécurisation des données
• Sécurisation des échanges
• Couche transverse
Couche - Autres
• Statistiques
• Logs
• Gestion des erreurs
• Gestion de la configuration
• Monitoring
• Etc…
Développer un modèle architectural
• Esquisse
• Décomposer en sous-systèmes
• Identifier des composants
• Sélectionner un style
• Raffiner
• Identifier les interactions
• Emplacement des données et des traitements
• Ajuster pour chaque cas d’utilisation
• Détailler et faire évoluer
Choix d’un framework
existant ?
Propriétés du système
• Persistance
• Granularité, volume, durée, mode d’accès, fréquence d’accès
• Fiabilité
• Communication, latence, synchronicité, volume, protocole
• Interfaces avec autres systèmes
• Latence, durée, mécanisme, fréquence
• Sécurité
• Users, datas, règles, privilèges
• Autres…
Workshop RFQ
• Requête pour un prix
• Le vendeur demande un prix
• Le trader donne le prix
• Si le vendeur accepte, l’ordre va être exécuté sur le marché
• Il peut modifier sa demande et renvoyer la requête
• L’ordre peut être exécuté en totalité ou en partie
• L’ordre exécuté va être enregistré dans les systèmes
• La compliance peut consulter les ordres exécutés
RFQ - 1
1. Requête pour cotation
2. Notification
3. Réponse
4. Réponse
5. Audit de la réponse
Vendeur
Tradeur
1
2
3
4
5
RFQ - 2
1. Vendeur accepte
2. Enregistrement de l’ordre
3. Envoi de l’ordre
4. Accusé de réception
Vendeur
1
2
3
4
RFQ - 3
1. Ordre envoyé
2. Retour d’exécution
3. MAJ de l’ordre
4. Rapport au vendeur
1
2
3
4
Vendeur
RFQ - 4
1. Demande de
consultation
2. Historiques des
ordres
1
2
Auditeur
Workshop
• Créer une architecture
Exemple de document d’architecture
Javascript
Angular4
Présentation Logique RFQ
SQL
Connecteur
Referentiel
Requete
Notification
Websocket
Stomp.js
Bus ActiveMQ
HTTPS
Rest
Historique
EventSourcing
Invocation implicite
• Par événement
• Publisher – Consumer
• Ordonnancement ?
Publisher Consommateur
Bus à message - broker
• Message oriented midleware MOM
• File d’attente asynchrone
• Interface de communication
• Transformation
Bus
Architecture évènements - dépendances
• Permet d’inverser des dépendances !
Architecture orientée Service - SOA
• Un service est auto-suffisant
• Un service gère un état
• Les services correspondent par messages décrit dans des schémas
• Ils sont aussi:
• Localisable
• Instance unique
• Couplage faible (communication par standard)
• Synchrone ou asynchrone
SOA
• Basé sur un bus
• Médiateur entre le producteur et le consommateur (middleware)
• Orienté Web
• Web support du service => Protocole, routage…
• Problèmes de performance ?
StateFull - StateLess
• Avec ou sans états
• Etat = représentation du client côté serveur
• Souvent représenté via un context ou une session
• Persisté ?
• Partagé ?
SOAP
• Schéma WSDL, description des services
• XML, messages structurés
• Transport http
• Annuaire UDDI, découverte des services
REST – Representational state transfer
• Service RestFull
• Client – Server
• Sans états (stateless)
• N’est pas un protocole !
• Url de base http://api.exemple.com/resources
• Méthode HTTP standard GET/PUT/POST/DELETE
• Type MIME
Cloud – Informatique nuagique
• IaaS Infrastructure as a service
• PaaS Plateforme as a service
• DaaS Data as a service
• SaaS Software as a Service
• FaaS Function as a Service
• Ressources en libre service
• Ouverture & Standard
• Mutualisation
• Paiement à l’usage
Cloud
Source: wikipédia
SaaS
• Customisation par configuration
• Pas d’accès aux données internes
• API d’accès
• Mashup = combinaisons de services dans un composant léger
FaaS –
Function as a Service -
ServerLess
• Stateless
• Event driven
• A la demande
• Pricing en ~ ms
Questions
https://www.slideshare.net/gataneleouet
Micro-Services
• Elastique
• Mise à l’échelle, Stateless, routing, load-balancing, registration, service naming
• Résilient
• Une panne n’impacte qu’une seule fonctionnalité
• Composable
• Agrégation, caching, proxies…
• Minimal
• Single responsability principle
• Complet
• Fonctionnellement complet
Micro-Services - Conséquences
• Possède ses propres datas
• Bounded Context (Prog. Fonctionnelle, DDD)
Minimal et complet
Micro-Services - Conséquences
• Registre des micro-services
• Nommage
• Service discovery
Registre
Elastique
Micro-Services - Conséquence
• Load Balancing
Elasticicté
Load Balancer
Micro-Services - Conséquences
• Communication asynchrone
• Gestion du downtime
Résilient
Micro-Service - Conséquences
• De nombreux services à livrer
• Environnement de Continuous Delivery
Minimal
Micro-Services - Conséquences
• De nombreux services
• Monitoring Centralisé !
• Granularité des services ?
• Localité physique des services ?
• Impact des appels distants
• Monitoring réseau
• Monitoring polyglotte
• Monitoring Conteneurs ?
• Monitoring plateforme (self-impact) ?
Micro-Services - Conséquences
• Tolerant Reader
• be conservative in what you do, be liberal in what you accept from others.
• Jon Postel
Composable
A
v1.0
B v1.0
B v2.0
B v3.0
B v4.0
Temps
Micro-Services - Conséquences
• Organisation
• Any organization that designs a system (defined broadly) will produce a
design whose structure is a copy of the organization's communication
structure.
• -- Melvyn Conway, 1967
Source : martinfowler.com
Micro-Service - Résumé
• Ne fait qu’une chose
• Autonome
• Possède ses données
Micro-Services - Buzzword
• If you can’t build a well-structured monolith, what makes you think microservices
is the answer?
• Simon Brown (auteur de « Software Architecture for Developers » )
• Don’t even consider microservices unless you have a system that’s too complex to
manage as a monolith. The majority of software systems should be built as a
single monolithic application. Do pay attention to good modularity within that
monolith, but don’t try to separate it into separate services.
• Martin Fowler
• You are not Netflix, stop trying to be them!
• Russ Miles (expert micro-services)
Architecture Hexagonale
• Centrée sur le domaine métier
• Bounded Context
• Reporter les choix architecturaux
le plus tard possible
• Séparer métier et infrastructure
Hexagone
• Composant autonome
• Communique via des adapteurs
• Pas de couplage
Service discovery
• S’enregistrer
• Découvrir
• Simple Clé/Valeur distribué ?
Eureka
Load Balancing
• Charge applicative
• Charge reseau
Ribbon
Pause
Base de données
ORM – Mapping Objet Relationnel
• Conversion entre modèles
• Modèle Relationnel
• Lignes groupées par relation
• Modèle Objet
• Objet encapsule donnée et comportement
Base de données distribuée
• Données stockées sur différents systèmes
• Systèmes indépendants
• Façade unique
• Partitions
• Lignes
• Colonnes
• Réplication
Partitionnement horizontal - lignes
Clé Valeur
X 5
Y 7
Z 10
W 12
Clé Valeur
X 5
Clé Valeur
W 12
Clé Valeur
Y 7
Z 10
Partitionnement vertical - colonnes
Clé Valeur
X 5
Y 7
Z 10
W 12
Clé
X
Y
Z
W
Valeur
5
7
10
12
Réplication
Clé Valeur
X 5
Y 7
Z 10
W 12
Clé Valeur
X 5
Y 7
Clé Valeur
X 5
Z 10
Clé Valeur
Y 7
W 12
Clé Valeur
Z 10
W 12
Théorème CAP
• Cohérence
• Haute disponibilité
• Tolérance au partitionnement
Cohérence
Availability
Network
Partition
CAP - Cohérence
• La modification d’une donnée prend effet immédiatement
X = 5 X ?
5
CAP – Haute disponibilité
• Toutes les requêtes reçoivent une réponse
CAP – Tolérance au partitionnement
• Continuité en cas d’ajout/suppression de nœuds
Théorème CAP
• un système de calcul distribué ne
peut garantir à un instant T que
deux de ces contraintes mais pas les
trois
• Preuve formelle en 2002
Cohérence
ACID
Availability
Network
Partition
SGBD
NoSQL
Impossible
d’avoir les 3
SGBD ACID
• A – Atomicité – la transaction s’effectue en totalité ou pas du tout
• C – Cohérence – Une transaction fait passer le système d’un état
valide à un état valide
• I – Isolation – Indépendance des transactions
• D – Durabilité – Une transaction confirmée reste enregistrée
Base de données temporelles
• Temps valide : période de validité d’un fait
• Temps transaction : période de stockage d’un fait dans la base
• Etend le SQL classique
• Event sourcing
NoSQL (Not Only SQL)
• Haute disponibilité
• Tolérantes aux partitionnement
• Clé / Valeur
• Orienté documents
• Orienté colonnes
• Orienté graphe
• Série temporelle
In memory db
• Base de données en mémoire
• Pas de durabilité
• Scalabilité difficile
• Cache distribué ?
• SQL ?
Scalabilité
• Mémoire
• 20x plus chère que SSD
• 100x plus chère que HD
• Swap entrée/sortie très couteux en temps
Pages Index
+
NoSQL - Base de données Timeserie
• Données sur une série temporelle
• Aggregation ex: n/seconde n/minute n/heure
NoSQL – Clé valeur
• La valeur est un bloc de données
opaques
Clé Valeur
NoSQL – Orienté colonnes
• Des colonnes différentes pour chaque ligne
• Grande quantité de colonnes (~ millions)
• Requête par clé + colonnes
• Modèle One to Many
Clé
Colonne:valeur
Colonne:valeur
Colonne:valeur
Colonne:valeur
Colonne:valeur
Colonne:valeur
Colonne:valeur
…
Colonne:valeur
Colonne:valeur
NoSQL – Orienté graphe
• Relations non triviales ou changeantes
FlockDB
NoSQL – Orienté Document
• Indexation de champs du document
• Requêtes élaborées
Clé
Champ1:Valeur
Champ1:Valeur
Champ1:Valeur
Champ1:Valeur
ElasticSearch
• Basé sur Apache Lucene (librairie)
• Indexation et recherche de données
• Orienté documents
• Api REST
• Quasi temps réel
• Scalable
Stack ELK
• Elasticsearch
• Logstach
• Kibana
Outils
• Métriques
• Visualisation
JMX
Cabot
Message Broker (retour)
• Plus rapide (latence faible)
• Plus léger
• Centralisés ou p2p
Authentification - statefull
Serveur
d’authentification
Client
Login
Application
Id session
Session
Application
Authentification - stateless
• Le client conserve un token, qui contient ses autorisations
Serveur
d’authentification
Client
Login
Application
Token
Application
Atelier
Atelier – Vue Générale
Le système permet le fonctionnement d'une banque qui fournit des
services de paiement pour ses partenaires, ainsi qu’une gestion des
comptes
• Les partenaires de la banque peuvent effectuer des facturations pour leurs
clients (carte bancaire) par Internet. Cette opération peut éventuellement
faire appel à la banque du client facturé. Les partenaires sont facturés à
l'opération pour ce service (ex : 1% de commission de la banque).
• Les partenaires peuvent consulter leurs comptes de manière électronique
et voir l'historique de leurs facturations.
• De nouveaux partenaires peuvent créer un compte. Cela se fait dans les
locaux de la banque avec un conseiller qui accède au système avec un
ordinateur.
• Il doit être possible de récupérer des informations de comptabilité pour le
trésor public. Détails des transferts effectués avec les autres banques,
facturations, etc.
Atelier : Exigences non-fonctionnelles / Contraintes
• Le système doit avoir une haute disponibilité de service : pas d'arrêt du service de
facturation (ex : 99% de disponibilité), support d'une quantité importante de requêtes
simultanées (ex : max 600 req/mn), temps de réponse court (ex : <2ms)
• Une politique de sécurité d'accès doit être mise en place : facturation et consultation
avec identifiant, identification des conseillers pour les opérations dans les locaux
• Tous les échanges d'informations en dehors de la banque doivent être chiffrés
• Les transferts entre banques doivent respecter la norme XYZ (transactions, sécurité,
authentification)
• La mise en place du système pour la facturation chez un partenaire doit prendre moins
de 10 hommes-jours. Sauf problème de sécurité, il n'est pas envisageable d'appliquer des
mises-à-jour sur les logiciels déjà déployés (si il y en a) chez les partenaires.
• Il existe déjà des équipes de développement dont une spécialisée dans la finance, et une
autre dans les applications utilisateurs en Java.
• Le développement doit être parallélisé le plus possible et les temps réduits au maximum.
• La loi impose de fournir les informations de comptabilité en moins d'un jour après
demande officielle.

Contenu connexe

Tendances

Tendances (20)

Cours de Génie Logiciel / ESIEA 2013-2014
Cours de Génie Logiciel / ESIEA 2013-2014 Cours de Génie Logiciel / ESIEA 2013-2014
Cours de Génie Logiciel / ESIEA 2013-2014
 
Génie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architecturesGénie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architectures
 
Java & Etat de l'art
Java & Etat de l'artJava & Etat de l'art
Java & Etat de l'art
 
At2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville PublicAt2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville Public
 
Support POO Java première partie
Support POO Java première partieSupport POO Java première partie
Support POO Java première partie
 
Introduction àJava
Introduction àJavaIntroduction àJava
Introduction àJava
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vie
 
Présentation de JEE et de son écosysteme
Présentation de JEE et de son écosystemePrésentation de JEE et de son écosysteme
Présentation de JEE et de son écosysteme
 
J2EE vs .NET
J2EE vs .NETJ2EE vs .NET
J2EE vs .NET
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Soutenance mémoire de fin d'études
Soutenance mémoire de fin d'étudesSoutenance mémoire de fin d'études
Soutenance mémoire de fin d'études
 
Struts
StrutsStruts
Struts
 
Gérez votre laboratoire de tests avec Visual Studio 2010 Lab Management
Gérez votre laboratoire de tests avec Visual Studio 2010 Lab ManagementGérez votre laboratoire de tests avec Visual Studio 2010 Lab Management
Gérez votre laboratoire de tests avec Visual Studio 2010 Lab Management
 
Cours spring
Cours springCours spring
Cours spring
 
Cours Génie Logiciel - Introduction
Cours Génie Logiciel - IntroductionCours Génie Logiciel - Introduction
Cours Génie Logiciel - Introduction
 
applications-reparties
applications-repartiesapplications-reparties
applications-reparties
 
Java Software Development
Java Software DevelopmentJava Software Development
Java Software Development
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
 
Presentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub FoundationPresentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub Foundation
 
Agl2012
Agl2012Agl2012
Agl2012
 

Similaire à Esiea - 5A - Archi 1/3

Aspectize mdday2010
Aspectize mdday2010Aspectize mdday2010
Aspectize mdday2010
MD DAY
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
Christophe HERAL
 
Session en ligne: Découverte du Logical Data Fabric & Data Virtualization
Session en ligne: Découverte du Logical Data Fabric & Data VirtualizationSession en ligne: Découverte du Logical Data Fabric & Data Virtualization
Session en ligne: Découverte du Logical Data Fabric & Data Virtualization
Denodo
 

Similaire à Esiea - 5A - Archi 1/3 (20)

Meetup Devops Geneve 06/17- EBU Feedbacks
Meetup Devops Geneve 06/17- EBU Feedbacks Meetup Devops Geneve 06/17- EBU Feedbacks
Meetup Devops Geneve 06/17- EBU Feedbacks
 
Les métiers du web
Les métiers du webLes métiers du web
Les métiers du web
 
Présentation sharepoint 2013
Présentation sharepoint 2013Présentation sharepoint 2013
Présentation sharepoint 2013
 
Low code, lean et agilité sur les projets SHarePoint - SPS Dakar
Low code, lean et agilité sur les projets SHarePoint - SPS DakarLow code, lean et agilité sur les projets SHarePoint - SPS Dakar
Low code, lean et agilité sur les projets SHarePoint - SPS Dakar
 
SPS Dakar 2018 - Low code, lean et agilité - Sébastien Paulet
SPS Dakar 2018 - Low code, lean et agilité - Sébastien PauletSPS Dakar 2018 - Low code, lean et agilité - Sébastien Paulet
SPS Dakar 2018 - Low code, lean et agilité - Sébastien Paulet
 
Aspectize mdday2010
Aspectize mdday2010Aspectize mdday2010
Aspectize mdday2010
 
Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)
 
Aspectize meetup
Aspectize meetupAspectize meetup
Aspectize meetup
 
Le Cloud, une réponse à nos besoins - Apéro Digital avril 2019 - Pascal Martin
Le Cloud, une réponse à nos besoins - Apéro Digital avril 2019 - Pascal MartinLe Cloud, une réponse à nos besoins - Apéro Digital avril 2019 - Pascal Martin
Le Cloud, une réponse à nos besoins - Apéro Digital avril 2019 - Pascal Martin
 
chapitre 1 SI.pdf
chapitre 1 SI.pdfchapitre 1 SI.pdf
chapitre 1 SI.pdf
 
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
[Scrum Day 2011] Outillage Agile dans un environnement Microsoft
 
Introduction à Cloud Foundry Journée du Code 2017
Introduction à Cloud Foundry Journée du Code 2017Introduction à Cloud Foundry Journée du Code 2017
Introduction à Cloud Foundry Journée du Code 2017
 
Procima deck 7 May 2014
Procima deck 7 May 2014Procima deck 7 May 2014
Procima deck 7 May 2014
 
Saas Libre
Saas LibreSaas Libre
Saas Libre
 
Accéder au développement Dot.Net et Asp.Net
Accéder au développement Dot.Net et Asp.NetAccéder au développement Dot.Net et Asp.Net
Accéder au développement Dot.Net et Asp.Net
 
Session en ligne: Découverte du Logical Data Fabric & Data Virtualization
Session en ligne: Découverte du Logical Data Fabric & Data VirtualizationSession en ligne: Découverte du Logical Data Fabric & Data Virtualization
Session en ligne: Découverte du Logical Data Fabric & Data Virtualization
 
Gouvernance des projets SharePoint 2013
Gouvernance des projets SharePoint 2013Gouvernance des projets SharePoint 2013
Gouvernance des projets SharePoint 2013
 
Acquia et Arte : Drupal Camp Paris 2013
Acquia et Arte : Drupal Camp Paris 2013Acquia et Arte : Drupal Camp Paris 2013
Acquia et Arte : Drupal Camp Paris 2013
 
Nuxeo en mode cloud SWORD Group - Nuxeo Tour 2014
Nuxeo en mode cloud SWORD Group - Nuxeo Tour 2014Nuxeo en mode cloud SWORD Group - Nuxeo Tour 2014
Nuxeo en mode cloud SWORD Group - Nuxeo Tour 2014
 
Formation d'architecte logiciel AFCEPF
Formation d'architecte logiciel AFCEPFFormation d'architecte logiciel AFCEPF
Formation d'architecte logiciel AFCEPF
 

Esiea - 5A - Archi 1/3

  • 2. Architecture et design ? Du système à la ligne de code Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. “We have met the enemy, and he is us.” Martin Fowler - Who Needs an Architect?
  • 3. Gaëtan • Ingénieur ENSEEIHT • 10+ années d’expériences • Expert Java • Pratiques du développement • Concours d’IA • 2 enfants • Menuiserie • Cuisine • Photographie • …
  • 4. Meritis • Cabinet de conseil en technologies de l’information • 350 personnes • Technique • Métier • Gestion de projets • Opérationnels • http://www.meritis.fr
  • 5. Sommaire • Qu’est ce qu’est l’architecture ? • Atelier conception document • Architecture micro-service • Atelier micro-service
  • 6. Qu’est ce qu’est l’architecture • Design ? • Organisation ? • Histoire ?
  • 7. Introduction A ne pas faire chez soi ->
  • 8. Définition • Comment un système d’information doit être conçu • De manière symbolique et schématique
  • 11. Métier d’architecte • Documents d’architecture • Méthodologies • Outils de développement • Proof of concepts • Veille technologique
  • 12. Document d’architecture • Représente les interactions • Les différents éléments • Exemple Pinot (OLAP - LinkedIn)
  • 13. Document d’architecture • Exemple LMAX : • Détaillé au niveau des cœurs du processeur • Cache friendly collection • Le document sert à communiquer la structure qui satisfait les contraintes exprimées du système
  • 14. Méthodologie • Equipe • One team • Pizza team • TDD • BDD • Qualité … • Agile • Scrum • Kanban • Etc… • Contractuelle • Cycle en V • Intégration continue • Continuous delivery
  • 15. Outils de développement • Environnement de développement • Langage • Gestion de sources • Environnement de build • Supervision de la qualité • Suivi de code review • Matériel • Communiquer les bonnes pratiques
  • 16. Proof of concepts • Maturité des technologies • Adaptabilité aux besoins • Réécriture d’existant • Documentation • Minimum Viable Product ? • Simple Complete Lovable ? • Communiquer les concepts à étudier React.js Angular Polymer…
  • 17. Veille technologique • Suivi de l’existant et des nouvelles versions • Découverte des nouveautés • Suivi des technologies abandonnées • Production ? • Communiquer avec les différentes équipes
  • 18. Architecture Logiciel • Motivations • Historique • Définitions • Exemples • L’architecture est intégrée dans le travail de tous les développeurs
  • 19. L’art de construire des logiciels • Choix des langages, technologies, méthodologies • Structure résultante d’une application L’architecture n’est pas un art
  • 20. Motivations • Réduction des coûts • Augmentation de la qualité Un logiciel est fait pour durer dans le temps Projet Qualité Coût Délai
  • 21. Motivations • Evolution de l’application • Besoins • Technologies • Réglementation
  • 22. Qualité • Maintenabilité • Portabilité • Fiabilité • Efficacité • Facilité d’utilisation
  • 23. Critères de qualité logicielle • Interopérabilité • Portabilité • Compatibilité • Validité • Vérifiabilité • Intégrité • Fiabilité • Maintenabilité • Réutilisabilité • Extensibilité • Efficacité • Autonomie • Transparence • Composabilité • Simplicité
  • 24. Historique • Programmation structurée • Langage procédural • Architecture en flux d’instructions • Programmation par composants • Architecture statique • Architecture dynamique • Programmation objets • Architecture programme • Architecture données • Programmation fonctionnelle • Architecture hexagonale • Architecture serverless • Programmation agents • Architecture distribuée Complexité
  • 25. Historique • Des besoins de plus en plus complexes • Des équipes de plus en plus grandes • Des quantités de données plus importantes • Mieux comprendre le système • Travailler en isolation sur différentes parties • Extensions du système • Réutilisabilité C’est ici le rôle de l’architecture logicielle Pourquoi dans une slide historique ?
  • 26. Architecture logicielle (Garlan 2000) • Compréhension : vue de haut niveau, contraintes • Réutilisation : identification des « parties » communes • Construction : plan de développement • Evolution : points d’extensions • Analyse : cohérence, conformité, dépendances • Gestion : dépendances, impact des délais, ordonnancement Architecture Spécifications Code
  • 27. Définition(s) • Description d’un système complexe • Architecture = éléments + formes + motivations (Perry et Wolf) • La structuration d’un système informatique, matériel et logiciel, en termes de composants et d’organisation de ses fonctions ainsi que leur relations
  • 28. Choix et motivations • Technologies • Produits • Serveurs • Nature du projet • Délais • Coûts • Compétences disponibles • …
  • 29. Description d’une architecture : 4 + 1 Scénario Logique Processus Implémentation Physique Philippe Kruchten
  • 30. Vue logique vers vue physique • Vue logique • Principaux composants • Maximiser la cohésion • Minimiser le couplage • Vue Physique • Déploiement physique des différents services • Ressources • Contraintes Temps Abstraction
  • 31. 4 + 1 : Vue logique • Système décomposé en sous-systèmes • UML : Diagramme de package
  • 32. 4 + 1 : Vue implémentation • Implémentation du système en termes de composants et de connecteurs • UML : Diagramme de composants
  • 33. 4 + 1 : Vue processus • Aspect dynamique du système • Concurrence, performance, scalabilité • UML : diagrammes d’activité
  • 34. 4 + 1 : Vue physique • Topologie du système et connections physique • UML : diagramme de déploiement
  • 35. 4 + 1 : Scénario • Séquences d’interactions • Illustre et valide l’architecture • Point de départ • UML : Use cases • Agile : Users stories
  • 36. Composant • Unité autonome d’un système • Peut-être remplacé ou réutilisé • Elément d’implémentation • Représente un objet ou un sous-système • Différent d’une instance • Séparation des préoccupations (SoC)
  • 37. Composant • Interfaces offertes • Interfaces requise • Nom • UML Composant Interface offerte Interface requise
  • 38. Diagramme de déploiement • Ressources utilisées • Matériel • Programme utilisé • Connexions entre les nœuds • Protocole • Contraintes • Artefacts ( application, base de données, etc…)
  • 39. Déploiement • Ressources • Contraintes Analyse Serveur 1 Proxy Analyse Serveur 2 Bus Persistance Serveur 3 BDDBDDhost:port http:rest https:rest
  • 40. Style architectural • Définit composants, connecteurs, contraintes • Patron avec un vocabulaire commun • Lien avec les design patterns en programmation
  • 41. Pipeline • Traitement et transformation de données • Séquentiel ou pipeline • Unidirectionnel • Tampon, points de synchronisation Filtre Canal Synchro
  • 42. Centrée données • Entrepôt de données centralisé • Repository, par requête • Blackboard, par notification • Intégrité des données par design Client Client Référentiel BDD
  • 43. EventSourcing • Etat initial + suite évènements = état actuel • On sauvegarde l’état initial • On sauvegarde la suite d’évènements E E E E … Event Store Modèle Facade
  • 44. CQRS - Command Query Responsibility Segregation • Séparer la lecture de données QUERY • Séparer l’écriture COMMAND Query Command
  • 45. Client - Serveur • Les clients connaissent les serveurs • Les serveurs ne connaissent pas les clients • Séparation des tâches Client Serveur requête réponse Client Serveur requête réponse
  • 46. Distribuée • Chaque nœud est à la fois client et serveur • P2P • Paradigme de programmation
  • 47. MVC – Modèle Vue Contrôleur • Modèle contient les données • Vue présente les données • Contrôleur traite les actions Vue Modèle Contrôleur
  • 48. MVP – Modèle Vue Présentation • Pas d’interaction entre la vue et le modèle • La présentation organise les données à afficher dans la vue Vue Modèle Présentation
  • 49. 3 - Tiers • Présentation • Traitement métier • Persistance des données Présentation Application Persistance http query
  • 50. N - Tiers • Empilement de couches • Chaque couche a sa propre responsabilité et utilise la couche immédiatement en dessous Présentation Contrôleur Service Domaine Persistance Sécurité Technique
  • 51. Couche - Présentation • Client Lourd • Poste client • Client Léger • Navigateur web • Ecrans générés sur le serveur • Client Smart • Compromis • Single Page Application …
  • 52. Couche - Contrôleur • Contrôle la cinématique • Appels de service • Erreurs et exceptions • Sessions ? • Autorisations ?
  • 53. Couche - Service • Implémentation de la logique métier • Sécurité applicative • Transactions • Intégrité des transactions • Appels à la couche domaine
  • 54. Couche - Domaine • Règles métier statiques • Sans états • Accès aux objets métiers • Via la couche persistance • Domaine commun ?
  • 55. Couche - Persistance • Opérations CRUD • Abstraction des DAO et ORM • Vision objet du modèle • Supporte les transactions de la couche domaine
  • 56. Couche – Sécurité • Authentification • Autorisations • Intégrité • Sécurisation des données • Sécurisation des échanges • Couche transverse
  • 57. Couche - Autres • Statistiques • Logs • Gestion des erreurs • Gestion de la configuration • Monitoring • Etc…
  • 58. Développer un modèle architectural • Esquisse • Décomposer en sous-systèmes • Identifier des composants • Sélectionner un style • Raffiner • Identifier les interactions • Emplacement des données et des traitements • Ajuster pour chaque cas d’utilisation • Détailler et faire évoluer Choix d’un framework existant ?
  • 59. Propriétés du système • Persistance • Granularité, volume, durée, mode d’accès, fréquence d’accès • Fiabilité • Communication, latence, synchronicité, volume, protocole • Interfaces avec autres systèmes • Latence, durée, mécanisme, fréquence • Sécurité • Users, datas, règles, privilèges • Autres…
  • 60. Workshop RFQ • Requête pour un prix • Le vendeur demande un prix • Le trader donne le prix • Si le vendeur accepte, l’ordre va être exécuté sur le marché • Il peut modifier sa demande et renvoyer la requête • L’ordre peut être exécuté en totalité ou en partie • L’ordre exécuté va être enregistré dans les systèmes • La compliance peut consulter les ordres exécutés
  • 61. RFQ - 1 1. Requête pour cotation 2. Notification 3. Réponse 4. Réponse 5. Audit de la réponse Vendeur Tradeur 1 2 3 4 5
  • 62. RFQ - 2 1. Vendeur accepte 2. Enregistrement de l’ordre 3. Envoi de l’ordre 4. Accusé de réception Vendeur 1 2 3 4
  • 63. RFQ - 3 1. Ordre envoyé 2. Retour d’exécution 3. MAJ de l’ordre 4. Rapport au vendeur 1 2 3 4 Vendeur
  • 64. RFQ - 4 1. Demande de consultation 2. Historiques des ordres 1 2 Auditeur
  • 65. Workshop • Créer une architecture
  • 66.
  • 67. Exemple de document d’architecture Javascript Angular4 Présentation Logique RFQ SQL Connecteur Referentiel Requete Notification Websocket Stomp.js Bus ActiveMQ HTTPS Rest Historique EventSourcing
  • 68. Invocation implicite • Par événement • Publisher – Consumer • Ordonnancement ? Publisher Consommateur
  • 69. Bus à message - broker • Message oriented midleware MOM • File d’attente asynchrone • Interface de communication • Transformation Bus
  • 70. Architecture évènements - dépendances • Permet d’inverser des dépendances !
  • 71. Architecture orientée Service - SOA • Un service est auto-suffisant • Un service gère un état • Les services correspondent par messages décrit dans des schémas • Ils sont aussi: • Localisable • Instance unique • Couplage faible (communication par standard) • Synchrone ou asynchrone
  • 72. SOA • Basé sur un bus • Médiateur entre le producteur et le consommateur (middleware) • Orienté Web • Web support du service => Protocole, routage… • Problèmes de performance ?
  • 73. StateFull - StateLess • Avec ou sans états • Etat = représentation du client côté serveur • Souvent représenté via un context ou une session • Persisté ? • Partagé ?
  • 74. SOAP • Schéma WSDL, description des services • XML, messages structurés • Transport http • Annuaire UDDI, découverte des services
  • 75. REST – Representational state transfer • Service RestFull • Client – Server • Sans états (stateless) • N’est pas un protocole ! • Url de base http://api.exemple.com/resources • Méthode HTTP standard GET/PUT/POST/DELETE • Type MIME
  • 76. Cloud – Informatique nuagique • IaaS Infrastructure as a service • PaaS Plateforme as a service • DaaS Data as a service • SaaS Software as a Service • FaaS Function as a Service • Ressources en libre service • Ouverture & Standard • Mutualisation • Paiement à l’usage
  • 78. SaaS • Customisation par configuration • Pas d’accès aux données internes • API d’accès • Mashup = combinaisons de services dans un composant léger
  • 79. FaaS – Function as a Service - ServerLess • Stateless • Event driven • A la demande • Pricing en ~ ms
  • 81. Micro-Services • Elastique • Mise à l’échelle, Stateless, routing, load-balancing, registration, service naming • Résilient • Une panne n’impacte qu’une seule fonctionnalité • Composable • Agrégation, caching, proxies… • Minimal • Single responsability principle • Complet • Fonctionnellement complet
  • 82. Micro-Services - Conséquences • Possède ses propres datas • Bounded Context (Prog. Fonctionnelle, DDD) Minimal et complet
  • 83. Micro-Services - Conséquences • Registre des micro-services • Nommage • Service discovery Registre Elastique
  • 84. Micro-Services - Conséquence • Load Balancing Elasticicté Load Balancer
  • 85. Micro-Services - Conséquences • Communication asynchrone • Gestion du downtime Résilient
  • 86. Micro-Service - Conséquences • De nombreux services à livrer • Environnement de Continuous Delivery Minimal
  • 87. Micro-Services - Conséquences • De nombreux services • Monitoring Centralisé ! • Granularité des services ? • Localité physique des services ? • Impact des appels distants • Monitoring réseau • Monitoring polyglotte • Monitoring Conteneurs ? • Monitoring plateforme (self-impact) ?
  • 88. Micro-Services - Conséquences • Tolerant Reader • be conservative in what you do, be liberal in what you accept from others. • Jon Postel Composable A v1.0 B v1.0 B v2.0 B v3.0 B v4.0 Temps
  • 89. Micro-Services - Conséquences • Organisation • Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. • -- Melvyn Conway, 1967 Source : martinfowler.com
  • 90. Micro-Service - Résumé • Ne fait qu’une chose • Autonome • Possède ses données
  • 91. Micro-Services - Buzzword • If you can’t build a well-structured monolith, what makes you think microservices is the answer? • Simon Brown (auteur de « Software Architecture for Developers » ) • Don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services. • Martin Fowler • You are not Netflix, stop trying to be them! • Russ Miles (expert micro-services)
  • 92. Architecture Hexagonale • Centrée sur le domaine métier • Bounded Context • Reporter les choix architecturaux le plus tard possible • Séparer métier et infrastructure
  • 93. Hexagone • Composant autonome • Communique via des adapteurs • Pas de couplage
  • 94. Service discovery • S’enregistrer • Découvrir • Simple Clé/Valeur distribué ? Eureka
  • 95. Load Balancing • Charge applicative • Charge reseau Ribbon
  • 96. Pause
  • 98. ORM – Mapping Objet Relationnel • Conversion entre modèles • Modèle Relationnel • Lignes groupées par relation • Modèle Objet • Objet encapsule donnée et comportement
  • 99. Base de données distribuée • Données stockées sur différents systèmes • Systèmes indépendants • Façade unique • Partitions • Lignes • Colonnes • Réplication
  • 100. Partitionnement horizontal - lignes Clé Valeur X 5 Y 7 Z 10 W 12 Clé Valeur X 5 Clé Valeur W 12 Clé Valeur Y 7 Z 10
  • 101. Partitionnement vertical - colonnes Clé Valeur X 5 Y 7 Z 10 W 12 Clé X Y Z W Valeur 5 7 10 12
  • 102. Réplication Clé Valeur X 5 Y 7 Z 10 W 12 Clé Valeur X 5 Y 7 Clé Valeur X 5 Z 10 Clé Valeur Y 7 W 12 Clé Valeur Z 10 W 12
  • 103. Théorème CAP • Cohérence • Haute disponibilité • Tolérance au partitionnement Cohérence Availability Network Partition
  • 104. CAP - Cohérence • La modification d’une donnée prend effet immédiatement X = 5 X ? 5
  • 105. CAP – Haute disponibilité • Toutes les requêtes reçoivent une réponse
  • 106. CAP – Tolérance au partitionnement • Continuité en cas d’ajout/suppression de nœuds
  • 107. Théorème CAP • un système de calcul distribué ne peut garantir à un instant T que deux de ces contraintes mais pas les trois • Preuve formelle en 2002 Cohérence ACID Availability Network Partition SGBD NoSQL Impossible d’avoir les 3
  • 108. SGBD ACID • A – Atomicité – la transaction s’effectue en totalité ou pas du tout • C – Cohérence – Une transaction fait passer le système d’un état valide à un état valide • I – Isolation – Indépendance des transactions • D – Durabilité – Une transaction confirmée reste enregistrée
  • 109. Base de données temporelles • Temps valide : période de validité d’un fait • Temps transaction : période de stockage d’un fait dans la base • Etend le SQL classique • Event sourcing
  • 110. NoSQL (Not Only SQL) • Haute disponibilité • Tolérantes aux partitionnement • Clé / Valeur • Orienté documents • Orienté colonnes • Orienté graphe • Série temporelle
  • 111. In memory db • Base de données en mémoire • Pas de durabilité • Scalabilité difficile • Cache distribué ? • SQL ?
  • 112. Scalabilité • Mémoire • 20x plus chère que SSD • 100x plus chère que HD • Swap entrée/sortie très couteux en temps Pages Index +
  • 113. NoSQL - Base de données Timeserie • Données sur une série temporelle • Aggregation ex: n/seconde n/minute n/heure
  • 114. NoSQL – Clé valeur • La valeur est un bloc de données opaques Clé Valeur
  • 115. NoSQL – Orienté colonnes • Des colonnes différentes pour chaque ligne • Grande quantité de colonnes (~ millions) • Requête par clé + colonnes • Modèle One to Many Clé Colonne:valeur Colonne:valeur Colonne:valeur Colonne:valeur Colonne:valeur Colonne:valeur Colonne:valeur … Colonne:valeur Colonne:valeur
  • 116. NoSQL – Orienté graphe • Relations non triviales ou changeantes FlockDB
  • 117. NoSQL – Orienté Document • Indexation de champs du document • Requêtes élaborées Clé Champ1:Valeur Champ1:Valeur Champ1:Valeur Champ1:Valeur
  • 118. ElasticSearch • Basé sur Apache Lucene (librairie) • Indexation et recherche de données • Orienté documents • Api REST • Quasi temps réel • Scalable
  • 119. Stack ELK • Elasticsearch • Logstach • Kibana
  • 121. Message Broker (retour) • Plus rapide (latence faible) • Plus léger • Centralisés ou p2p
  • 123. Authentification - stateless • Le client conserve un token, qui contient ses autorisations Serveur d’authentification Client Login Application Token Application
  • 125. Atelier – Vue Générale Le système permet le fonctionnement d'une banque qui fournit des services de paiement pour ses partenaires, ainsi qu’une gestion des comptes • Les partenaires de la banque peuvent effectuer des facturations pour leurs clients (carte bancaire) par Internet. Cette opération peut éventuellement faire appel à la banque du client facturé. Les partenaires sont facturés à l'opération pour ce service (ex : 1% de commission de la banque). • Les partenaires peuvent consulter leurs comptes de manière électronique et voir l'historique de leurs facturations. • De nouveaux partenaires peuvent créer un compte. Cela se fait dans les locaux de la banque avec un conseiller qui accède au système avec un ordinateur. • Il doit être possible de récupérer des informations de comptabilité pour le trésor public. Détails des transferts effectués avec les autres banques, facturations, etc.
  • 126. Atelier : Exigences non-fonctionnelles / Contraintes • Le système doit avoir une haute disponibilité de service : pas d'arrêt du service de facturation (ex : 99% de disponibilité), support d'une quantité importante de requêtes simultanées (ex : max 600 req/mn), temps de réponse court (ex : <2ms) • Une politique de sécurité d'accès doit être mise en place : facturation et consultation avec identifiant, identification des conseillers pour les opérations dans les locaux • Tous les échanges d'informations en dehors de la banque doivent être chiffrés • Les transferts entre banques doivent respecter la norme XYZ (transactions, sécurité, authentification) • La mise en place du système pour la facturation chez un partenaire doit prendre moins de 10 hommes-jours. Sauf problème de sécurité, il n'est pas envisageable d'appliquer des mises-à-jour sur les logiciels déjà déployés (si il y en a) chez les partenaires. • Il existe déjà des équipes de développement dont une spécialisée dans la finance, et une autre dans les applications utilisateurs en Java. • Le développement doit être parallélisé le plus possible et les temps réduits au maximum. • La loi impose de fournir les informations de comptabilité en moins d'un jour après demande officielle.

Notes de l'éditeur

  1. OLAP traitement analytique en ligne (hypercube)
  2. Disruptor pour LMAX 6 millions ordres par seconde sur un seul thread
  3. Suivant le contexte peut désigner plusieurs aspect, le questionnement ou le résultat
  4. Zookeeper etcd filesystem distribué Fonctionne par quorum Gossip protocol propagation des donnees
  5. Problemes Proprietaire du shema Identité des issues Objet partiel/load time Probleme de transaction applicative != transaction DB performances
  6. Log structured merge tree LSM
  7. Voldemort -> LinkedIn LevelDB -> Google
  8. Hbase = Hadoop Database Cassandra developped by facebook Hypertable - alibaba
  9. Flockdb - twitter
  10. Lucene – text processing
  11. Kafka linkedIn