Dan Garlasu, dgarlasu@yahoo.

com

1
2
  L'architecture logicielle d'un système décrit ses principaux composants,
leurs relations et la manière dont ils interagissent les uns avec les autres.
 Il sert essentiellement de plan. Il fournit une abstraction pour gérer la
complexité du système et établir la communication et la coordination entre
les composants.

Voici quelques points clés :

• L'architecture permet de définir une solution répondant à l'ensemble des besoins
techniques et opérationnels, dans un objectif commun d'optimisation de la performance
et de la sécurité.
• La conception de l'architecture implique l'intersection des besoins de l'organisation
ainsi que des besoins de l'équipe de développement. Chaque décision peut avoir un
impact considérable sur la qualité, la maintenabilité, les performances, etc.
L'une des définitions préférées de l'architecture logicielle vient de Ralph Johnson, co-
auteur de Design Patterns: Elements of Reusable Object-Oriented Software. Il a déclaré
que :
« Ce sont les décisions que vous aimeriez pouvoir prendre dès le début d'un projet. »

3
En bref, les exigences fonctionnelles définissent ce qu'un système est censé faire,
comme dans le cas d'une voiture, emmener une personne de A à B, et les exigences
non fonctionnelles stipulent comment un système est censé être. Ces 10 principales
caractéristiques d'architecture non fonctionnelles couvrent la plupart des aspects d'un
projet à grande échelle:
1. Évolutivité (Scalability)
2. Disponibilité
3. Extensibilité
4. Cohérence (Consistency)
5. Résilience
6. Convivialité (Usability)
7. Observabilité
8. Sécurité
9. Durabilité
10. Agilité

4
 Ordre du jour
1. World-Wide-Web
 Solution architecturale de base
 Concevoir d'applications Web
2. CORBA
 Systèmes d'objets distribués
 CORBA : notions de base
 CORBA : les services
3. Systèmes de base de données
4. Systèmes en temps réel
Course content available at: coronet.iicm.tugraz.at/sa/scripts/lesson10.doc

This lesson presents a number of standard architectural solutions

5
 Les propriétés de base du WWW sont:
◦ Accès à distance au contenu
◦ Interopérabilité entre différentes plateformes
◦ Extensibilité du logiciel
◦ Extensibilité des données
◦ Évolutivité
 L'approche architecturale de base
utilisée dans le WWW:
◦ Style d’architecture client/serveur;
◦ Protocole de transfert HTTP (hypertexte) qui
sert de couche d’echage de données au
niveau application
◦ Format de données spécial HTML qui
masque toutes les dépendances matérielles,
de système d'exploitation et de protocole

6
PPP = Point to Point Protocol
SLIP = Serial Line Internet Protocol

7
 Les producteurs et les consommateurs de contenu interagissent via leurs
serveurs et clients respectifs

 Le producteur place le contenu sur une machine serveur et le contenu est

décrit en HTML. Le serveur communique avec un client en utilisant le
protocole de transfert hypertexte (HTTP).
 Le logiciel sur le serveur/client sont basé sur HTTP et HTML; ainsi les détails
du protocole et les dépendances des plates-formes sont masqués du logiciel

8
 Les propriétés WWW de base s’appuient sur des solutions architecturales:
◦ Accès à distance = Construit au-dessus d'Internet
◦ Interopérabilité = Utilise HTML pour masquer les détails de la plate-forme
◦ Extensibilité du logiciel = Programmation coté Serveur et coté Client dans le Style de
Machine Virtuelle
◦ Extensibilité des données = permet références à tous types de données
◦ Évolutivité = style d'architecture client-serveur et références locales à d'autres données

9
 L'un des principaux composants du WWW est un client Web qui
affiche des documents WWW (contenu) de sorte que le
consommateur de contenu se voit présenter une image
compréhensible et avec la possibilité d'accéder à d'autres
documents connexes.

10
  Le gestionnaire d'interface utilisateur (User Interface Manager) gère
l'aspect et la convivialité (look & feel) de l'interface utilisateur client.
 Cependant, étant donné que l'ensemble des ressources qu'un système Web
peut gérer est ouvert, le gestionnaire d'interface utilisateur peut déléguer
l'affichage des informations à des programmes externes (visualiseurs) pour
afficher les ressources connues du système mais non directement
supportées par le gestionnaire d'interface utilisateur.

Par exemple, la plupart des visualiseurs Web utilisent un programme externe pour
afficher des fichiers Postscript, des graphiques vectoriels et des films. Cette délégation
est un compromis raisonnable entre les désirs concurrents d'intégration de l'interface
utilisateur (qui fournit une apparence et une convivialité cohérentes et donc une
meilleure convivialité) et l'extensibilité.

11
 Le gestionnaire d'interface utilisateur capture la demande de récupération
d'informations d'un utilisateur sous la forme d'une URL et transmet les
informations au gestionnaire d'accès. Le gestionnaire d'accès détermine si
l'URL demandée existe dans le cache et interprète également la navigation
basée sur l'historique (par exemple, «retour», «avant», etc.)

12
 Le planificateur de flux est un composant architectural important pour
synchroniser les opérations de traitement de données locales "rapides"
effectuées par le gestionnaire d'interface utilisateur et les opérations d'accès
aux données et de transfert de données relativement "lentes" effectuées par
le gestionnaire de cache et le gestionnaire de protocole.

 Le planificateur de flux peut être vu comme une file d'attente de requêtes

pour effectuer des opérations d'entrée/sortie et de transfert de données.

13
 Le gestionnaire de protocole gère les communications de bas
niveau, assurant ainsi, pour les autres parties du système, une
communication transparente à travers un réseau. Le gestionnaire de
protocole détermine le type de demande et invoque la suite de
protocoles appropriée pour traiter la demande

14
  Le serveur WWW assure un accès transparent à l'énorme collection
de documents qui est en fait un objectif principal du WWW. Pour ce
faire, le serveur gère l'accès directement (pour les types de ressources
connus) ou via un proxy appelé interface de passerelle commune
(CGI – Common Gateway Interface). CGI gère les types de ressources
qu'un serveur natif ne peut pas traiter et gère aussi l'extension des
fonctionnalités du serveur, comme nous le verrons ci-dessous.

HTTP est un protocole inventé au CERN par Sir Tim-Berners Lee. L'idée de départ
était de permettre aux scientifiques de partager des documents (c'est pourquoi nous
appelons les pages HTML des documents HTML).

15
 Le planificateur de requêtes est un composant architectural important
pour synchroniser les requêtes provenant simultanément de plusieurs
clients (souvent très nombreux) et d'autres composants du serveur
partageant une seule unité de traitement de données.

 Le planificateur de requêtes peut être vu comme une file d'attente des

requêtes des clients vers le serveur

16
 Le gestionnaire de session utilisateur est un composant architectural permettant
de résoudre un conflit entre le serveur servant simultanément de nombreux
utilisateurs et la personnalisation de l'accès d'un utilisateur particulier.

 Normalement, le gestionnaire de session utilisateur conserve les données

spécifiques à l'utilisateur (par exemple, le statut de l'utilisateur, le nom de connexion,
etc.), identifie un utilisateur pour chaque demande particulière et récupère les
données spécifiques à l'utilisateur pour exécuter correctement la demande.

17
  Lorsqu'une requête est reçue par le gestionnaire de requêtes, le
type de requête est déterminé.
◦ Si un fichier connu est demandé, le serveur HTTP accède au système de
fichiers et écrit les informations demandées dans le flux de sortie.
◦ Si un programme doit être exécuté, un processus est mis à disposition
(nouveau ou interrogé) via le CGI et le programme est exécuté, la sortie étant
écrite par le gestionnaire de requêtes du serveur vers le client Web.

Dans les deux cas, CGI est l'un des principaux moyens par lesquels les serveurs
assurent l'extensibilité, et la facilité d'extensibilité est devenue l'une des exigences les
plus importantes à l'origine de l'évolution des logiciels Web. CGI est devenu un aspect
important des applications Web.

18
 La plupart des informations servies par un serveur sont statiques; ils ne
changent que lorsque leur auteur les modifie sur son système de fichiers
personnel. L'interface de passerelle commune (CGI), d'autre part, permet
à un serveur de renvoyer des informations dynamiques spécifiques à la
demande. L'utilisation la plus courante de CGI consiste à créer des
documents HTML virtuels, qui sont synthétisés dynamiquement en réponse
à une demande de l'utilisateur.
Les applications CGI sont écrites dans
une variété de langages, dont certains
sont compilés (C, C++, ...) et d'autres
exécutés sous le contrôle d'une
machine virtuelle compatible CGI (Java
Scripts, Java Servlets, PHP scripts,
CGI scripts, etc. )

19
 Ainsi, la technologie Web peut être considérée comme un environnement d'exploitation pour
le développement d'applications distribuées complètes:
◦ HTTP sert de protocole de transport
◦ HTML sert comme interface utilisateur graphique
◦ La fonctionnalité orientée vers l'objectif est implémentée en tant qu'application compatible CGI

En fait, le terme
application compatible
CGI peut être vu comme
un accès Internet à
n'importe quelle
application locale
(SGBD, tableur, système
expert, etc.)

20
 Malheureusement, toutes ces applications Internet rencontrent des
problèmes communs :
◦ Performance: tous les calculs demandés par un certain nombre de clients sont effectués
sur le serveur, ce qui allonge le temps de réponse.
◦ Convivialité (usage): HTML ne fournit pas de solutions d'interface utilisateur graphique à
jour telles que le glisser/déposer (drag/drop), l'animation, les graphiques vectoriels, etc.
◦ Trafic Internet: presque toutes les actions de l'utilisateur entraînent la génération et le
transfert de fichiers HTML assez volumineux qui augmentent considérablement le trafic
Internet et les coûts globaux du système pour les utilisateurs.

21
 Bien sûr, la technologie Web fournit une autre solution pour construire des
applications compatibles WWW - des applications sur site client. Un
serveur WWW particulier peut simplement fournir un accès à des
applications orientées vers un objectif, qui sont interprétées par un client
Web

 Déplacer des calculs vers un site client augmente considérablement les

performances et diminue le trafic Internet. Dans le même temps, toutes
ces applications Internet rencontrent des problèmes d'interface utilisateur
et en particulier d'incompatibilité de navigateur.

22
 Parmi les éléments suivants, indiquez lesquels sont des
propriétés WWW de base (choisissez toutes les réponses qui
s'appliquent) :
a. Accès à distance au contenu
b. Interopérabilité entre différentes plateformes
c. Extensibilité des logiciels et des données
d. Évolutivité
e. L'intégration

Reponses: a, b, c, d.

23
  Parmi les éléments suivants, indiquez lesquels constituent
l'approche architecturale de base utilisée pour WWW
(choisissez toutes les bonnes réponses):
a. Style client/serveur
b. Norme HTTP
c. Norme HTML
d. Norme SQL
e. Norme CORBA

Reponses: a, b, c.

24
  Les systèmes d'objets distribués sont des systèmes distribués dans
lesquels toutes les entités sont modélisées comme des objets.
 Les systèmes d'objets distribués sont un paradigme populaire pour
les applications distribuées orientées objet. Étant donné que
l'application est modélisée comme un ensemble d'objets coopérants,
elle correspond très naturellement aux services du système
distribué.
 CORBA, ou Common Object Request Broker Architecture, est une
architecture standard pour les systèmes d'objets distribués qui
permet à une collection distribuée et hétérogène d'objets d'interagir.

Vous souvenez-vous de ce qu'est la SOA ? Une architecture orientée services est

essentiellement un ensemble de services. Ces services communiquent entre eux. La
communication peut impliquer soit un simple transfert de données, soit deux services
ou plus coordonnant certaines activités. Certains moyens de connecter les services les
uns aux autres sont nécessaires.

Les architectures orientées services ne sont pas une nouveauté. La première

architecture orientée services pour de nombreuses personnes dans le passé consistait
à utiliser DCOM ou Object Request Brokers (ORB) basé sur la spécification CORBA.

25
  Donc, CORBA étant une architecture pour les systèmes d'objets
distribués, cela signifie essentiellement deux choses :
◦ Une fonctionnalité du système est définie au moyen d'un paradigme de
programmation orienté objet.
◦ Le calcul est distribué sur un réseau.
 Dans le paradigme de la programmation orientée objet:
◦ Un système se présente sous forme d'Objets;
◦ Les objets (Clients) demandent des services à d'autres objets (Servants);
◦ Tout le reste est défini par CORBA en fonction de ce paradigme de base;

Un calcul distribué est mis en œuvre sur une transparence de localisation. Exactement
le même mécanisme de requête est utilisé par le client, quel que soit l'emplacement du
serveur. Cela peut être dans le même processus avec le client, au bout du couloir ou à
travers la planète. Le client ne peut pas faire la différence

26
  La transparence de l'emplacement est implémentée sous la forme d'un
composant spécial appelé ORB (Object Request Broker)

 ORB est un environnement de réseau informatique spécial, assurant le

transport des requetes et des données, d'un emplacement physique à un
autre.
 Dans CORBA, chaque instance d'objet a sa propre référence d'objet
unique, c’est-à-dire un jeton électronique d'identification (token).

Les clients utilisent les références d'objet pour diriger leurs invocations, en identifiant à
l'ORB l'instance exacte qu'ils souhaitent invoquer (en s'assurant, par exemple, que les
livres que vous sélectionnez vont dans votre propre panier, et non dans celui de votre
voisin.) – C’est la propriété de persistance.

27
 CORBA sépare essentiellement l'interface objet de l'implémentation.
 Une interface est définie au moyen d'un langage spécial, IDL (Interface
Definition Language). Tout client qui souhaite invoquer une opération sur
l'objet, doit utiliser cette interface IDL pour spécifier l'opération qu'il
souhaite effectuer et pour aligner les arguments qu'il envoie.
L'interface de chaque objet est définie très
strictement. En revanche, l'implémentation d'un
objet - son code d'exécution et ses données -
est cachée du reste du système (c'est-à-dire
encapsulée) derrière une frontière que le client
ne peut pas franchir. Les clients accèdent aux
objets uniquement via leur interface annoncée,
en appelant uniquement les opérations que
l'objet expose via son interface IDL, avec
uniquement les paramètres (entrée et sortie)
qui sont inclus dans l'invocation.

28
 Une définition d'interface (IDL) est compilée dans
◦ talons de client (client stub) - utilisés pour demander un service et
◦ squelettes d'objets (object skeletons) utilisés pour fournir un service.
 Les talons et les squelettes servent de proxys pour les clients et les serveurs,
respectivement
Lorsque l'invocation atteint l'objet
cible, la même définition d'interface
est utilisée pour démarquer les
arguments afin que l'objet puisse
effectuer l'opération demandée avec
eux. La définition d'interface est
ensuite utilisée pour rassembler les
résultats pour leur voyage de retour
et pour les démarquer lorsqu'ils
atteignent leur destination.

29
 Afin d'invoquer l'instance d’un objet distant, le client obtient d'abord
sa référence d'objet
 Il existe de nombreuses façons de le faire, par exemple au moyen du
Service de nommage (Naming) et du Marchand (Trader Service)
Le client agit comme s'il invoquait
une opération sur l'instance d'objet,
mais il invoque en fait le talon
(stub) IDL qui agit comme un
proxy. En passant par le talon au
côté client, l'invocation se poursuit
par l'ORB (Object Request Broker),
et par le squelette côté
implémentation, pour arriver à
l'objet où il est exécuté.

30
 CORBA a standardisé le processus de collaboration entre les
objets, à deux niveaux clés :
1. Le client connaît le type d'objet qu'il appelle (qu'il s'agit d'un objet panier,
par exemple), et le talon client et le squelette d'objet sont générés à
partir du même IDL. Cela signifie que le client sait exactement quelles
opérations il peut invoquer, quels sont les paramètres d'entrée et où ils
doivent aller dans l'invocation; quand l'invocation atteint la cible, tout est
là et au bon endroit.
Pour pouvoir le faire, le système doit avoir accès
à des informations sur l'emplacement et
l'environnement d'exploitation de l'objet. La base
de données contenant ces informations est
appelée Référentiel de mise en œuvre
(Implementation Repository) et est un
composant standard de l'architecture CORBA.
Le référentiel de mise en œuvre peut également
contenir d'autres informations relatives à la mise
en œuvre des serveurs, telles que le débogage,
la version et les informations administratives.

31
2. L'ORB du client et l'ORB de l'objet doivent convenir d'un protocole
commun - c'est-à-dire une représentation pour spécifier l'objet cible,
l'opération, tous les paramètres (entrée et sortie) de chaque type qu'ils
peuvent utiliser, et comment tout cela est représenté sur le fil (la voie
de communication).
Cette fonction est remplie par le protocole général
inter-ORB (GIOP); il a été spécifiquement défini
pour répondre aux besoins d'interaction ORB à ORB
et est conçu pour fonctionner sur n'importe quel
protocole de transport qui répond à un ensemble
minimal d'hypothèses. Bien entendu, les versions de
GIOP implémentées à l'aide de transports différents
ne seront pas nécessairement directement
compatibles; cependant leur interaction sera rendue
beaucoup plus efficace. Outre la définition de la
syntaxe générale de transfert, GIOP précise
également comment il va être mis en œuvre à l'aide
du transport TCP/IP et définit ainsi le protocole
Internet Inter-ORB (IIOP).

32
 Les services d'objets sont des interfaces indépendantes du domaine qui
sont utilisées par de nombreux programmes d'objets distribués.
 Par exemple, un service permettant de découvrir (Rechercher) d'autres
services disponibles est presque toujours nécessaire quel que soit le
domaine d'application.
 Voici deux exemples de services d'objet remplissant ce rôle :
◦ Le service de nommage - permet aux clients de trouver des objets basés sur des noms;
◦ Le service de trading (commercialisation) - permet aux clients de trouver des objets a
partir de leurs propriétés

33
 Il existe également des spécifications de service d'objet pour:
◦ Gestion du cycle de vie,
◦ Sécurité,
◦ Transactions,
◦ Notification d'événement, etc.
 Fonctionnalités communes – Comme les interfaces de service d'objet, ces
interfaces sont également orientées horizontalement, mais contrairement aux
services d'objet, elles sont orientées vers les applications de l'utilisateur final.
◦ Un exemple d'une telle facilité est la DDCF (Distributed Document Component Facility),
une facilité commune de document composite basée sur OpenDoc.
◦ DDCF prend en charge une interopérabilité des objets basée sur un modèle de document,
par exemple, en facilitant la liaison d'un objet de feuille de calcul dans un document de
rapport.

34
 La programmation des systèmes distribués traditionnels est complexe
• L'échange de données nécessite une synchronisation
• La bande passante disponible est limitée
• Les dépendances temporelles sont compliquées
• Il est difficile de faire face aux défaillances partielles du système

Ken Arnold, créateur de CORBA :

"L'échec est la différence déterminante entre la programmation distribuée et
locale, vous devez donc concevoir des systèmes distribués en envisageant
la possibilité d’un échec »;
– Les développeurs passent plus de temps à concevoir en cas d'échec qu'à
travailler sur le problème lui-même.

1-35

Ken Arnold est l'un des concepteurs de CORBA (mais pas le seul). Il a ensuite aidé à concevoir Jini alors
qu'il était employé chez Sun Microsystems, il en sait donc beaucoup sur l'informatique distribuée.

Même dans une simple application graphique, un développeur passera beaucoup de temps à écrire du
code de gestion des erreurs. La complexité de l'informatique distribuée amplifie cela de manière
significative, de sorte que vous pouvez facilement passer plus de temps à gérer les échecs que vous
n'en passerez à gérer le succès dans votre code.

Les « sophismes de l'informatique distribuée » attribués à Peter Deutsch et à d'autres chez Sun
Microsystems sont également pertinents. Les numéros 1, 3 et 7 sont particulièrement importants pour la
conception de Hadoop.
1. Le réseau est fiable.
2. La latence est nulle.
3. La bande passante est infinie.
4. Le réseau est sécurisé.
5. La topologie ne change pas.
6. Il y a un administrateur.
7. Le coût du transport est nul.
8. Le réseau est homogène.
35
 Veuillez choisir l'énoncé correct dans la liste ci-dessous
concernant CORBA :
a. une architecture pour les systèmes d'objets distribués
b. le calcul est centralisé sur un réseau
c. la fonctionnalité du système est définie au moyen d'un
paradigme de programmation fonctionnelle

Response: a.

36
 ORB (Object Request Broker) c'est :
a) une référence objet unique,
b) un environnement de réseau informatique spécial assurant
le transport des demandes et des données d'un
emplacement physique à un autre
c) un jeton électronique d'identification

Response: b.

37
 Dans CORBA, le langage de définition d'interface (IDL) est
compilé en (choisissez toutes les bonnes réponses):
a) talons de client (utilisés pour demander un service)
b) squelettes d'objets (utilisés pour fournir un service)
c) un jeton électronique d'identification

Response: a, b.

38
 L'architecture de n'importe quel SGBDR (Système de Gestion Bases
de Données Relationnelles) est hétérogène. Ces systèmes utilisent
non seulement un style architectural, mais plutôt ils combinent un
certain nombre de styles architecturaux dans une architecture
logicielle complexe.

39
  Au niveau supérieur, le SGBDR peut être considéré comme un système client/serveur. Le
client est le processus qui émet des commandes spéciales de traitement de données
(transactions de base de données). Les transactions de base de données sont traitées par le
serveur qui accède réellement à la base de données. Ainsi, le serveur:
◦ Contrôle les fichiers physiques contenant les données;
◦ Vérifie la connexion et les privilèges de l'utilisateur;
◦ Prend charge de la structure logique et physique de la base de données (intégrité);
◦ Optimise les transactions pour augmenter les performances;
◦ Gère les transactions reçues de plusieurs clients.
Normalement, un SGBDR possède un
certain nombre de clients prêts à l'emploi,
permettant à un utilisateur de travailler de
manière interactive avec une base de
données à l'aide d’instructions SQL ou
autre langage de manipulation de
données (PLSQL). Ces clients sont
appelés clients système.

Le modèle client-serveur se compose de deux parties ; un serveur et plusieurs clients.

Le composant serveur fournira des services à plusieurs composants clients. Les clients
demandent des services au serveur et le serveur fournit des services pertinents à ces
clients. De plus, le serveur continue d'écouter les requêtes des clients.

40
 Une application de base de données est implémentée sous la forme
d'un certain nombre de clients ciblés (purpose-oriented) qui
utilisent des API spéciales pour lancer des transactions de base de
données. Les transactions sont intégrées dans le code pour
accéder/modifier la base de données. Dans ce cas, le langage de
programmation est appelé langage de programmation hôte (Host
Programming Language)

41
 Conceptuellement, un serveur de base de données est construit à
l'aide d'une architecture en couches. Nous pouvons distinguer:
◦ Couche de communication qui fournit une communication transparente
entre le serveur et les clients indépendamment de leur position physique.
◦ Couche logique qui implémente les principales fonctionnalités du SGBDR
conformément au modèle de données logique pris en charge par le système.
◦ Couche physique qui masque toutes les dépendances matérielles, de
système d'exploitation et de protocole.

42
 Normalement, la couche logique est formée des composants suivants :
◦ Gestionnaire de transactions (Transaction Manager) qui accumule et met en file
d'attente les transactions de données reçues de différents clients.
◦ Gestionnaire de session (Session Manager) qui résout un conflit entre le serveur servant
simultanément de nombreux utilisateurs et la personnalisation de l'accès d'un utilisateur
particulier;
◦ Moteur de transaction (Transaction Engine) qui analyse, optimise et exécute les
transactions de base de données;
◦ Moteur de récupération qui contrôle si une transaction a été effectuée avec succès et
récupère la base de données en cas de situations erronées.

Notez que le moteur de

transaction et le moteur
de récupération sont
construits au-dessus des
fonctionnalités fournies
par la couche physique

43
 La couche physique d'un serveur de base de données comprend:
◦ Gestionnaire de tampon (Buffer Manager) qui contrôle les éléments de la base de
données en mémoire principale (RAM). Les problèmes typiques résolus par le composant
sont la réduction des opérations de lecture/écriture en conservant les parties de la base
de données les plus fréquemment consultées dans la mémoire active (RAM).
◦ Gestionnaire de ressources contrôle des éléments de données supplémentaires tels
que journaux de base de données, indicateurs, index construits dynamiquement, etc.
◦ Gestionnaire de stockage (Storage Manager) qui implémente une plate-forme et des
opérations d'accès au stockage indépendantes de location.

44
 Choisissez ci-dessous toutes les activités que le serveur
effectue dans les transactions de base de données :
a) Contrôle les fichiers physiques contenant les données
b) Vérifie la connexion et les privilèges de l'utilisateur
c) Prend en charge la structure logique et physique de la
base de données (intégrité)
d) Optimise les transactions pour augmenter les
performances
e) Gère les transactions reçues de plusieurs clients

Response: a, b, c, d, e.

45
 La couche physique d'un serveur de base de données se compose des
composants suivants (choisissez tous ceux qui s'appliquent) :
a) Buffer Manager qui contrôle les éléments de la base de données
en RAM.
b) Gestionnaire de ressources qui contrôle des éléments de
données supplémentaires tels que les journaux de base de
données, les indicateurs, les index construits dynamiquement, etc.
c) Gestionnaire de stockage qui implémente une plate-forme et
positionne les opérations d'accès au stockage indépendantes
d) Responsable ramasseur de déchets de mémoire (Garbage
collector)

Response: a., b, c.

46
 Les systèmes en temps réel fonctionnent dans des conditions
temporelles fortes (contraintes), ils sont par nature distribués et
dynamiques.
 Afin de refléter ces propriétés, l'architecture du logiciel pour les
systèmes en temps réel qui surveillent, contrôlent ou simulent les
processus du monde réel doivent fournir des moyens adéquats pour
faire face au temps, à la concurrence et à la décentralisation.

47
  Le plus souvent, les systèmes en temps réel sont conçus en utilisant
le style architectural "événementiel" (Event).
 De plus, l'architecture en temps réel doit refléter les tâches
suivantes:
◦ horodatage de tous les processus impliqués (time-stamping).
◦ planification de toutes les ressources impliquées

L'architecture événementielle est celle dans laquelle le flux d'exécution d'un

programme est déterminé par les événements.

48
 Le récepteur d'événements reçoit tous les événements des capteurs
externes et des composants internes du système. De plus, il:
◦ fournit un horodatage d'événement à l'aide d'une horloge globale haute résolution
◦ calcule le temps jusqu'au moment où l'événement doit être traité
◦ envoie l'événement horodaté (c'est-à-dire une soi-disant tâche) au planificateur de tâches

49
 Le planificateur de tâches contrôle l'ordre dans lequel les tâches sont
exécutées par le système. On peut l’apercevoir comme un élément
dynamique qui change les priorités des tâches comme suit :
◦ pour chaque tâche le système garde un temps moyen nécessaire pour la réaliser et son
importance relative;
◦ la priorité peut être calculée à l'aide d'une restriction de temps particulière, d'une
importance relative et de l'heure système actuelle;
◦ le planificateur de tâches sélectionne une tâche ayant la priorité la plus élevée et l'envoie
au gestionnaire de processus qui lance un processus spécial pour un composant logiciel
spécialement conçu. Notez que si le gestionnaire de tâches rencontre une tâche ayant
une priorité plus élevée que le processus en cours d'exécution, le processus est
interrompu.

Le scénario d'attribution de priorité ci-

dessus est appelé scénario "pire cas".
Cependant, c'est un problème non trivial
de trouver l'importance relative des
tâches telles que l'ensemble du système
se comporte de manière optimale.

50
 Puisqu'il peut y avoir un certain nombre de processus exécutés
simultanément, les ressources (mémoire, périphériques d'entrée/sortie,
etc.) peuvent être redistribuées entre les processus.
 C’est le gestionnaire de ressources qui alloue des ressources de
système aux processus conformément à leur priorité relative. Par
exemple, conformément à la stratégie du "pire cas", toutes les
ressources système sont allouées à un processus si la priorité de la
tâche atteint une certaine valeur critique (ca veut dire que la tâche est
un risque pour l'ensemble des fonctionnalités du système).

51
 L'architecture logicielle des systèmes en temps réel qui
surveillent, contrôlent ou simulent les processus du monde réel
doit fournir des moyens adéquats pour faire face (choisir tout
ce qui s'applique) :
a) Temps,
b) Coût,
c) Concurrence,
d) Décentralisation

Response: a,c, d.

52
  La conception pour portabilité est de plus en plus adoptée, car des cadres disponibles
(comme Dapr) se concentrent sur un modèle d'abstraction natif du cloud et permettent
aux architectes de séparer la logique métier des détails de mise en œuvre.
 Les grands modèles de langage vont avoir un impact significatif, qu'il s'agisse d'aider à
comprendre les compromis architecturaux ou d'autonomiser une nouvelle génération de
développeurs low-code et no-code.
 La durabilité des logiciels sera une considération de conception majeure dans les
années à venir. Des travaux sont en cours pour mieux mesurer puis réduire l'empreinte
carbone des systèmes logiciels.
 Les applications décentralisées prennent la blockchain au-delà de la crypto-monnaie et
des NFT, mais le manque de demande des consommateurs en fera un modèle de niche.
 Les architectes sont toujours à la recherche d'améliorations sur la façon de documenter,
de communiquer et de comprendre les décisions. Cela peut être un autre domaine où
les grands modèles de langage joueront un rôle à l'avenir.

Design for portability and the concept of cloud-bound applications, got one of the popular frameworks Dapr, that's D-A-P-R, (not
confused with dapper, D-A-P-P-E-R, the Distributed Application Runtime).

Tous ceux qui travaillaient sur de grands modèles de langage ont regardé ChatGPT, et ont dit : "nous devons produire cela, nous
allons rater le train." Et c'est en fait bien parce que, dans un sens, on a l'impression que nous envisageons peut-être le début d'un
nouvel été ou d'un printemps d'IA, où la pression de sortir un produit peut en fait produire quelque chose d'assez utile, et tout le
monde essaie pour voir ce que le modèle peut faire.

Tous ces modèles de langage vont être un énorme catalyseur pour les systèmes low-code/no-code. ChatGPT ne pouvait créer que
des composants, un fichier, etc., des choses simples. GPT-4 est beaucoup plus amélioré. Vous pouvez réellement générer des sites
Web simples entiers, mais quand même. Cela pourrait en fait être une nouvelle abstraction des langages de programmation. Parce
que nous sommes partis de l'assembleur, puis nous avons eu C et C++, puis nous nous sommes lancés dans toutes sortes de
langages Java et .NET et de niveau supérieur.

En ce qui concerne Blockchain et applications décentralisées, Blockchain s'est assis sur la section des innovateurs du graphique
des tendances, je pense, depuis qu'il est apparu et nous ne l'avons pas déplacé car il ne s'applique qu'aux crypto et NFT et cela ne
semblait tout simplement pas intéressant. Le seul cas auquel je puisse penser qu'une application décentralisée ait réussi concernait
le partage de fichiers, les torrents et des trucs comme ça.

« Architecte en tant que leader technique", "Quel rôle as-tu en tant qu'architecte ?" Comment dirigez-vous, et aussi, comment nous
en sortons-nous avec le travail à distance et hybride, toutes ces choses sur la façon dont nous faisons l'architecture. Il suffit de
s'assurer qu'il y a toujours des lignes de communication ouvertes avec les personnes qui sont en train de construire, de dépanner et
de déboguer et qui sont impliquées dans ces appels à 3h00 du matin. C'est la seule façon de vraiment comprendre si ce que nous
concevons fonctionne et a de la valeur, puis d'appliquer ces leçons au projet suivant.

53