Dan Garlasu, dgarlasu@yahoo.

com

1
 Ordre du jour
1. Qu'est-ce qu'une architecture du logiciel
2. Attributs de qualité du système
3. Le processus d'architecture technique
4. Le processus d'architecture organisationnelle
5. Styles architecturaux

Sources:
Software Architecture: It Might Not Be What You Think It Is (infoq.com)
Why You Should Care about Software Architecture (infoq.com)

Le développement de logiciels peut être décrit comme un processus systémique

complexe qui nécessite une expertise dans diverses sphères de la technologie ainsi
que dans l'entreprise concernée. Une partie intégrante de ce processus de
développement logiciel est facilitée par la définition de l'architecture du logiciel à la
manière d'un schéma directeur d'un plan directeur.

Source: Everything About Software Architecture (by Mohit Malhotra)

2
3
 Une architecture est
◦ Un ensemble de décisions importantes concernant l'organisation d'un système logiciel;
◦ Une sélection des éléments structuraux et de leurs interfaces qui composent le système;
◦ Un comportement des éléments structuraux tel que spécifié dans les collaborations entre
ces éléments;
◦ Composition de ces éléments structuraux et comportementaux en sous-systèmes de plus
en plus grands;
◦ Un style architectural qui guide cette organisation (c'est-à-dire ces éléments et leurs
interfaces, leurs collaborations et leur composition);
 L'intention de cette définition est qu'une architecture logicielle doit extraire
certaines informations du système (sinon, il est inutile de regarder
l'architecture, nous visualisons simplement l'ensemble du système) et fournir
suffisamment d'informations pour servir de base à l'analyse, à la décision
fabrication, et donc la réduction des risques.

L'intention de cette définition est qu'une architecture du logiciel doit extraire certaines
informations du système (sinon, il est inutile de regarder l'architecture, nous
visualisons simplement l'ensemble du système) et fournir suffisamment d'informations
pour servir de base à l'analyse, à la décision fabrication, et donc la réduction des
risques.
Au départ, les développeurs avaient l'habitude de concevoir des logiciels sans
architecture, ce qui apparaît initialement comme un avantage de ne pas avoir de
surcharge de planification ainsi qu'un prototypage plus rapide. Mais au fur et à
mesure qu'ils approfondissaient le processus, le logiciel est devenu inflexible et
ingérable, tout comme une boule de boue. Comme chaque changement devient plus
coûteux, cette approche a ensuite été appelée une ‘grosse boule de boue’ (Big Ball of
Mud).
Un tel projet devient ingérable avec le temps et augmente donc considérablement les
coûts de maintenance à chaque nouvelle itération. Cela contraint le logiciel à évoluer
au-delà des limites initialement définies en début de projet.

4
 Tout d'abord, l'architecture définit les
composants. L'architecture contient des
informations sur la façon dont les
composants interagissent les uns avec
les autres. Cela signifie que
l'architecture omet spécifiquement les
informations de contenu sur les
composants qui ne concernent pas leur
interaction
 Examples:
◦ Client/Serveur
◦ Architecture à 3 niveaux (3-Tier Architecture)
◦ Data Oriented Architecutre(DOA)
◦ Services Oriented Architecture

Nous allons analyser chaque élément constitutif de l'architecture, en commençant par

les Composants.

5
 Deuxièmement, la définition mentionne que les systèmes peuvent
comprendre plus d'une structure et qu'aucune structure spécifique ne détient
la prétention irréfutable d'être l'architecture. Par intention, la définition ne
précise pas ce que sont les composants architecturaux et les relations.
 Qu’est-ce que ce qu’un composant logiciel?
◦ un objet?
◦ un processus?
◦ une bibliothèque?
◦ une base de données ?
◦ Un produit commercial ?
 Cela peut être n'importe laquelle de ces choses et plus encore…
 Ne confondez pas les termes architecture et configuration!

In general, architecture refers to the overall design of a system or application,

including its components and their relationships to each other. It defines how the
system is structured and how its components interact with each other.
On the other hand, configuration refers to the specific settings and parameters that
are used to customize a system or application. It includes things like network settings,
user preferences, and other options that can be adjusted to meet specific needs.

6
 Troisièmement, la définition implique que chaque système logiciel a
une architecture, car il peut être démontré que chaque système est
formé de composants et de relations entre eux.

So while architecture defines the overall structure of a system, configuration defines

how that system is customized to meet specific requirements.

7
 Quatrièmement, le comportement de chaque composant fait partie
de l'architecture, dans la mesure où ce comportement peut être
observé ou discerné du point de vue d'un autre composant.
 Ce comportement est ce qui permet aux composants d'interagir les
uns avec les autres, ce qui fait clairement partie de l'architecture.
 Par conséquent, la plupart des dessins en forme de boîte et de ligne
qui sont présentés comme des architectures ne sont en fait pas du
tout des architectures. Ce sont simplement des dessins en forme de
boîte et de ligne!

8
 Cinquièmement, l'architecture définit essentiellement les propriétés "visibles
de l'extérieur", également appelées attributs de qualité du système pour
l'ensemble du projet logiciel.
 Nous nous référons à des propriétés telles que:
◦ prestations fournies,
◦ caractéristiques de performance,
◦ traitement des pannes,
◦ l'utilisation des ressources partagées, etc.
 L'évaluation des propriétés d'une architecture est essentielle au développement réussi d'un
système. Cependant, le raisonnement sur l'architecture prévue d'un système doit être
reconnu comme distinct du raisonnement sur son architecture réalisée. Au fur et à mesure de
la conception et éventuellement de la mise en œuvre d'une architecture, la fidélité aux
principes de l'architecture prévue n'est pas toujours facile à atteindre. Cela est
particulièrement vrai dans les cas où l'architecture prévue n'est pas complètement spécifiée,
documentée ou diffusée à tous les membres du projet.

9
 Certains attributs d'un système dominé par logiciel définissent la
fonctionnalité du système et sont visibles lors de l'exécution:
◦ La performance fait référence à la réactivité du système - le temps
nécessaire pour répondre aux stimuli (événements) ou le nombre
d'événements traités dans un certain intervalle de temps.
◦ Les qualités de performance sont souvent exprimées par le nombre de
transactions par unité de temps ou par le temps nécessaire à l'exécution
d'une transaction avec le système.
◦ Étant donné que la communication prend généralement plus de temps que
le calcul, les performances dépendent souvent du degré de
communication et d'interaction entre les composants du système -
clairement un problème d'architecture!

Exemples de qualité d'exécution:

TPS – Transactions par seconde

Temp de response a une commande: doit etre moins de 2-3 secondes

10
 La sécurité est une mesure de la capacité du système à résister aux:
◦ tentatives d'utilisation non autorisées et
◦ déni de service tout en fournissant ses services aux utilisateurs légitimes (DOS/DDOS)
 La sécurité est classée en termes de types de menaces qui pourraient
être faites au système;
 Exemples:
◦ Escroqueries par hameçonnage (Phising scams)
◦ Bogues de sécurité qui permettent aux intrus d'entrer : Heartbleed, Venom…
◦ Données volées et modifiées : Stuxnet, etc.
 Qu'est-ce qui motive l’ensemble de mesures de sécurité?:
◦ Utilisation du Média social
◦ Utilisation d’équipement personnel au travail (BYOD – Bring Your Own Device)
◦ Cloud computing – savez-vous où se trouve votre courriel ou messagerie vocale?
◦ Big Data – nous permet de combiner des choses sur les gens (Personal Data Privacy)

11
 La disponibilité mesure la proportion de temps pendant laquelle le système
est opérationnel.
 Il est mesuré par :
◦ La durée entre les pannes (MTBF – Mean Time Between Failures) ainsi que par
◦ La rapidité avec laquelle le système est capable de reprendre le fonctionnement en cas de
panne (MTTR – Mean Time To Repair)
 La disponibilité en régime permanent d'un système est la proportion de
temps pendant laquelle le système fonctionne correctement et est
généralement considérée comme suit :
durée entre les pannes / (durée entre les pannes + temps de réparation)
 La disponibilité dépend à la fois du «durée entre les pannes» et du «temps
de réparation» ; les deux sont traités par des moyens architecturaux.

Exemples:
DisponibilitéTelecom: 99.999% - connue come “Telco grade” ou “Carrier grade”.
Ca veut dire que pendant un an, le système peut être innopérationnel pour 365 x 24 x
60 /0,001 = 525 min

12
 La fiabilité, étroitement liée à la disponibilité, est la capacité
du système à continuer à fonctionner dans le temps. La fiabilité
est généralement mesurée par le « temps jusqu'à la panne». Il
s'agit d'un attribut de qualité lié à l'architecture :
◦ une attention particulière aux rapport et traitement des erreurs (ce qui
implique de limiter les modèles d'interaction entre les composants) et
des types spéciaux de composants tels que les moniteurs de délai
d'attente (time-out monitors).
 MTTR - Temps moyen de réparation
 MTBF - Temps moyen entre pannes

13
 Source: Software Architecture: It Might Not Be What You Think It Is (infoq.com)

Relations entre QAR (Quality Attribute: Reliability), Decision, and Technical Debt
• Quelle dette technique vous avez sciemment contractée. Certaines décisions créeront
inévitablement et inéluctablement une limitation technique; par exemple, la décision
d'atteindre des objectifs de fiabilité en utilisant une base de données SQL a des effets
secondaires sur la limitation technique (voir Figure 1).
• Le «problème Y2K» désormais révolu était une décision consciente prise par les
développeurs à l'époque qui réduisait le stockage des données, l'utilisation de la
mémoire et les besoins en temps de traitement en ne stockant pas les données du
siècle dans le cadre des représentations de date standard. Le problème était qu'ils ne
s'attendaient pas à ce que les applications durent aussi longtemps, longtemps après
que ces contraintes ne soient plus pertinentes. S'ils avaient communiqué leurs
décisions et décrit plus précisément l'impact potentiel, il n'y aurait peut-être pas eu une
telle bousculade pour réagir à la fin du siècle dernier.

14
 Le temps moyen entre pannes (MTBF) est allongé (augmenté)
principalement en rendant une architecture tolérante aux pannes.
 La tolérance aux pannes, à son tour, est obtenue par la réplication
des éléments d’exécution critiques et des connexions au sein de
l'architecture.
 Le temps moyen entre pannes peut également être allongé en
créant un système moins vulnérable aux erreurs, qui est résolu
architecturalement par une séparation minutieuse des activités, ce
qui conduit à une meilleure
◦ inerrabilité (liberté ou exemption d'erreur; infaillibilité) et
◦ testabilité.

15
 La fonctionnalité est la capacité du système à effectuer le travail pour
lequel il a été conçu.
 L'exécution d'une tâche nécessite que plusieurs ou la majorité des
composants du système fonctionnent de manière coordonnée pour aboutir
le travail, tout comme les charpentiers, les électriciens, les plombiers, les
peintres et les menuisiers de finition se réunissent tous pour effectuer en
coopération la tâche d'obtenir une maison construite.
 Par conséquent, si on n’a pas attribué aux diverses composantes des
bonnes responsabilités ou celles-ci n'ont pas été dotées des installations
adéquates pour se coordonner avec d'autres composantes (afin qu'elles
sachent, par exemple, quand il est temps pour elles de commencer leur
part de la tâche), le système ne pourra pas exécuter la fonctionnalité
requise.

16
 L'utilisabilité peut être décomposée dans les domaines suivants :
◦ Capacité d'apprentissage: Dans quelle mesure est-il rapide et facile pour un utilisateur
d'apprendre à utiliser l'interface du système ?
◦ Efficacité: le système répond-il avec une rapidité appropriée aux demandes d'un
utilisateur ?
◦ Mémorabilité: l'utilisateur peut-il se rappeler comment effectuer les opérations du système
entre les utilisations du système ?
◦ Évitement des erreurs: le système anticipe-t-il et prévient-il les erreurs courantes des
utilisateurs ?
◦ Gestion des erreurs: le système aide-t-il l'utilisateur à se remettre des erreurs ?
◦ Satisfaction: Le système facilite-t-il le travail de l'utilisateur ?
 Il existe d'autres attributs d'un système à logiciel intensif qui ne peuvent pas
être discernés lors de l'exécution. Ils sont abordés dans les sous-sections
suivantes Distinguer entre efficacité et efficience.

• L'efficacité (efficacy) signifie faire avancer les choses. Le mot « efficacité » est surtout
utilisé dans un contexte scientifique. ...
• L’Efficience signifie bien faire les choses. Une fois que vous avez trouvé une solution
efficiente, vous pouvez alors essayer de l'améliorer en la rendant plus efficace.

17
 La modifiabilité, sous toutes ses formes, peut être l'attribut de
qualité le plus étroitement aligné sur l'architecture d'un système.
 La possibilité d'apporter des modifications rapidement et de manière
rentable découle directement de l'architecture : la possibilité de
modification dépend en grande partie de la localité de toute
modification.
 Une modification généralisée du système est plus coûteuse que la
modification d'un seul composant, toutes choses égales par ailleurs.
 Puisque l'architecture définit les composants et les responsabilités
de chacun, elle définit également les circonstances dans lesquelles
chaque composant devra changer.

Il y a des exceptions, bien sur.

Un seul composant, s'il est excessivement volumineux et complexe, peut être plus
coûteux à modifier que cinq composants simples.
Il est aussi facile d'imaginer un changement global qui en chaque lieu soit simple et
systématique: changer la valeur d'une constante qui apparaît partout, par exemple.

Cependant, dans les grands systèmes, faire un changement est beaucoup plus
coûteux que simplement, eh bien, faire le changement. Les coûts du processus de
développement commencent à dominer, tels que le maintien du contrôle des versions,
l'approbation du changement dans de nombreux tableaux de contrôle des
changements, la coordination du temps de changement dans de nombreuses grandes
équipes, le retest de toutes les unités, peut-être la garantie de la rétrocompatibilité, etc.
Nous prenons comme principe général que le local est meilleur.

18
 Une architecture classifie efficacement tous les changements possibles en 4 catégories :
1. Extension ou modification des capacités. Ajouter de nouvelles fonctionnalités, améliorer
les fonctionnalités existantes ou réparer des bogues.
 La possibilité d'acquérir de nouvelles fonctionnalités s'appelle l'extensibilité. L'ajout de nouvelles
fonctionnalités est important pour rester compétitif par rapport aux autres produits sur le même marché.
2. Suppression des fonctionnalités indésirables. Pour rationaliser ou simplifier la
fonctionnalité d'une application existante, peut-être pour fournir une version moins
performante (et donc moins chère) d'un produit à une clientèle plus large.
3. Adaptation aux nouveaux environnements d'exploitation. Par exemple, le matériel du
processeur, les périphériques d'entrée/sortie et les périphériques logiques. Ce type de
modification se produit si souvent que la qualité de s'y prêter porte un nom spécial: la
portabilité - dont nous parlerons séparément. La portabilité rend un produit plus flexible
dans la façon dont il peut être mis en service, attirant une clientèle plus large.
4. Restructuration. Par exemple, rationaliser les services du système, modulariser, optimiser
ou créer des composants réutilisables qui peuvent servir à donner à l'organisation une
longueur d'avance sur les futurs systèmes.

Quand Steve Jobs a rejoint Apple, a suite de la fusion avec Next, - afin de limiter les
pertes d’Apple, Steve Jobs a adopte la strategie: “on acheve plus si on fait moins”, en
réduisant de 1000 produits à une disaine de produits.

19
 La portabilité est la capacité du système à fonctionner sous différents
environnements informatiques.
 Ces environnements peuvent être matériels, logiciels ou une combinaison
des deux. Un système est portable dans la mesure où toutes les hypothèses
concernant un environnement informatique particulier sont confinées à un
seul composant (ou, au pire, à un petit nombre de composants facilement
modifiables).
 L'encapsulation des considérations spécifiques à la plate-forme dans une
architecture prend généralement la forme d'une couche de portabilité - un
ensemble de services logiciels qui donne au logiciel d'application une
interface abstraite avec son environnement. Cette interface reste constante
(en isolant ainsi le logiciel d'application du changement) même si la mise en
œuvre de cette couche change à mesure que le système est porté d'un
environnement à l'autre.

Exemple: SGBDR d’Oracle

20
  La réutilisabilité est généralement considérée comme signifiant
la conception d'un système de sorte que la structure du système
ou certains de ses composants puissent être réutilisés dans de
futures applications.
 Concevoir pour la réutilisabilité signifie que le système a été
structuré de manière à ce que ses composants puissent être
choisis parmi des produits déjà construits, auquel cas il est
synonyme d'intégrabilité.
 Dans les deux cas, la réutilisabilité peut être conçue comme un
autre cas particulier de modifiabilité.

On va discuter le concept d’intégrabilité dans la diapo suivante.

21
 L'intégrabilité est la capacité à faire fonctionner correctement ensemble les
composants du système développés séparément.
 Cela dépend à son tour de :
◦ la complexité externe des composants,
◦ leurs mécanismes et protocoles d'interaction, et
◦ la mesure dans laquelle les responsabilités ont été clairement réparties.
 L'intégrabilité dépend également de la mesure dans laquelle les interfaces
des composants ont été bien et complètement spécifiées. L'intégration d'un
composant dépend non seulement des mécanismes d'interaction utilisés (par
exemple, appel de procédure par rapport à la génération de processus), mais
également de la fonctionnalité attribuée au composant à intégrer et de la
manière dont cette fonctionnalité est liée à la fonctionnalité de
l'environnement de ce nouveau composant.

22
 L'interopérabilité est un type particulier d'intégrabilité.
 Mais quelle est la différence entre Intégrabilité et Interopérabilité?
 L'intégrabilité mesure la capacité des parties d'un système à
fonctionner ensemble ;
 l'interopérabilité mesure la capacité d'un groupe de parties
(constituant un système) à fonctionner avec un autre système.

23
 La testabilité du logiciel fait référence à la facilité avec laquelle un logiciel peut être amené à
démontrer ses défauts par le biais de tests (généralement basés sur l'exécution).
 En particulier, la testabilité fait référence à la probabilité que, en supposant que le logiciel ait
au moins un défaut, le logiciel échoue lors de sa prochaine exécution de test.
 Pour qu'un système soit correctement testable, il doit être possible de contrôler l'état interne
et les entrées de chaque composant, puis d'observer ses sorties.
 La testabilité d'un système concerne plusieurs problèmes structurels ou architecturaux:
◦ son niveau de documentation architecturale,
◦ sa séparation des préoccupations (separation of concerns),
◦ la mesure dans laquelle le système utilise le masquage d'informations.
 Le développement incrémental profite également à la testabilité de la même manière qu'il
améliore l'interopérabilité

24
 En plus des qualités précédentes qui s'appliquent directement à
un système, il existe un certain nombre d'objectifs de qualité
métier qui façonnent fréquemment l'architecture d'un système.
 Nous distinguons (brièvement) deux types d'objectifs
commerciaux :
1. Le premier concerne les considérations de coût et de
planification;
2. L'autre objectif commercial traite des considérations de
marché et de marketing

25
 Temps de commercialisation (time to market). S'il existe une
pression concurrentielle ou s'il existe une courte fenêtre d'opportunité
pour un système ou un produit, le temps de développement devient
important.
◦ Cela conduit à son tour à une pression pour acheter ou réutiliser les
composants existants.
 Le temps de mise sur le marché est souvent réduit en utilisant des
composants prédéfinis tels que des produits commerciaux prêts à
l'emploi de type COTS (Commerical Off The Shelf) ou des composants
réutilisés à partir de projets antérieurs. La possibilité d'insérer un
composant dans un système dépend de la décomposition du système
en composants, dont un ou plusieurs sont préconstruits

C'est une question assez importante.

C'est pourquoi nous avons attribué le cours n° 7 à ce sujet : Prêt a porter envers
construit sur mesure.

26
 Coût. L'effort de développement aura naturellement un budget à ne pas
dépasser.
◦ Différentes architectures entraîneront des coûts de développement différent; par exemple,
une architecture qui s'appuie sur une technologie qui n'est pas résidente dans
l'organisation en développement sera plus coûteuse à réaliser qu'une architecture qui tire
parti d'actifs déjà internes.
 Durée de vie projetée du système. Si le système est destiné à avoir une
longue durée de vie, la possibilité de modification et la portabilité sur
différentes plates-formes devient importante. Mais l'intégration d'une
infrastructure supplémentaire (telle qu'une couche de portabilité) pour
prendre en charge la modificabilité et la portabilité compromettra
généralement le temps de mise sur le marché.
◦ D'un autre côté, un produit modifiable et extensible a plus de chances de survivre plus
longtemps sur le marché, prolongeant ainsi sa durée de vie.

27
 Marché ciblé. Pour les logiciels à usage général (marché de
masse), les plates-formes sur lesquelles un système fonctionne ainsi
que son ensemble de fonctionnalités détermineront la taille du
marché potentiel. Ainsi, la portabilité et la fonctionnalité sont
essentielles pour la part de marché. D'autres qualités telles que la
performance, la fiabilité et la convivialité (usability) jouent également
un rôle.
 Pour un marché important mais spécifique, une approche par
gamme de produits doit être envisagée, dans laquelle
◦ un noyau du système est commun (incluant souvent des dispositions pour la
portabilité) et autour duquel
◦ des couches de logiciels de spécificité croissante sont construites

On peut prolonger la discussion ici avec la Théorie de l'adoption des nouvelles

technologies (Jeoffrey Moore, …), a voire APPs #1.

28
 Calendrier de déploiement. Si un produit doit être introduit en tant que
fonctionnalité de base avec de nombreuses options, la flexibilité et la
personnalisation sont importantes. En particulier, le système doit être
construit en gardant à l'esprit la facilité d'expansion et de contraction. Ainsi
l’importance de la feuille de route du produit (product roadmap)!
 Utilisation extensive des systèmes hérités. Si le nouveau système doit
s'intégrer aux systèmes existants, il faut veiller à définir des mécanismes
d'intégration appropriés.
◦ Il s'agit d’une propriété dont l'importance commerciale est évidente mais dont les
implications architecturales sont importantes.
◦ Par exemple, la possibilité d'intégrer un système hérité avec un serveur HTTP pour le
rendre accessible à partir du World Wide Web pourrait être un objectif marketing pour
beaucoup d’organisations. Les contraintes architecturales impliquées par cette intégration
doivent être analysées.

Exemple: Interation Oracle/Tuxido pour les mainframes IBM.

29
 Cout rentable. Non seulement Oracle offrira des prix compétitifs avec ses services
d'infrastructure cloud, mais il aidera les clients en automatisant autant que possible leurs
opérations cloud – Base de données autonome.
 Fiabilité. Il ne peut y avoir de point de défaillance unique, en fait, il ne peut pas y avoir de
défaillances du tout.
 Performance. Plus vite vous exécutez, moins de ressources que vous utilisez pour faire
avancer les choses.
 Conception basée sur des standards. Facilite le «levage et le déplacement (lift & shift)»
des applications sur site vers le cloud.
 Compatibilité complète. La technologie sur site et les services cloud Oracle seront
compatibles.
 Sécurité "toujours active". Au niveau de la base de données et du silicium. En termes de
priorité d'entreprise, Ellison a déclaré : "Je mettrais la sécurité au premier plan."

30
  Le processus d'architecture inclut:
◦ un processus technique (étapes et heuristiques
pour créer une bonne architecture)
◦ un processus organisationnel.
 Le livrable central du processus
d'architecture est la spécification
architecturale, motivant et décrivant la
structure du système à travers différentes
vues. Cependant, bien que la structuration
du système soit au cœur du processus
d'architecture, ce n'est qu'une des
nombreuses activités essentielles à la
création d'une bonne architecture..

Heuristique (provient du grec ancien εὑρίσκω (heurískō) 'je trouve, découvre'), ou

technique heuristique, est toute approche de résolution de problèmes ou d'auto-
découverte qui emploie une méthode pratique qui n'est pas garantie d'être optimale,
parfaite, ou rationnel, mais néanmoins suffisant pour atteindre un objectif ou une
approximation immédiate à court terme.

31
 Les exigences architecturales sont nécessaires pour focaliser les activités
structurantes. Différentes approches architecturales ont tendance à produire
différents degrés d'adéquation aux diverses exigences du système, et
l'évaluation des alternatives ou la réalisation d'analyses de compromis
architecturaux sont un complément important à la phase de structuration.
 Les exigences architecturales sont un sous-ensemble des exigences du
système, déterminées par la pertinence architecturale. Les objectifs
commerciaux du système, et de l'architecture en particulier, sont importants
pour s'assurer que l'architecture est alignée sur l'agenda commercial.
 Le contexte du système aide à déterminer ce qui est dans la portée contre ce
qui est hors de portée, quelle est l'interface système et quels facteurs
affectent l'architecture.

Il existe des cours spéciaux traitant de ces sujets tels que: ITIL, TOGAF, prérequis pour
devenir architecte informatique.

32
 La proposition de valeur du système aide à établir comment le système
s'adaptera à l'agenda des utilisateurs et aux objectifs de haut niveau et
hautement prioritaires. Ces objectifs sont traduits en un ensemble de cas
d'utilisation, qui constituent la base pour documenter les exigences
fonctionnelles. La structure du système échoue si elle ne prend pas en
charge les services ou les fonctionnalités que les utilisateurs apprécient, ou
si les qualités associées à cette fonctionnalité inhibent les performances de
l'utilisateur ou sont autrement insatisfaisantes.

Cas d’utilization, en englais: Use Case scenarios.

33
 Les qualités du système qui ont une importance architecturale (par exemple, les
performances et la sécurité, mais pas la convivialité au niveau de l'interface
utilisateur) sont donc également importantes pour orienter les choix architecturaux
lors de la structuration.
 Bien sûr, les exigences peuvent déjà avoir été collectées par les équipes de produit.
Dans ce cas, l'équipe d'architecture doit examiner ces exigences pour la pertinence
et l'exhaustivité de l'architecture (en particulier en ce qui concerne les exigences non
fonctionnelles) et se préoccuper des exigences des futurs produits que l'architecture
devra prendre en charge.
◦ Exemple: objectifs de conception du service Cloud
 Enfin, pour l'architecture d'une gamme ou d'une famille de produits, les exigences
architecturales propres à chaque produit et celles qui sont communes à l'ensemble
des produits doivent être distinguées afin que la structure puisse être conçue pour
prendre en charge à la fois les points communs et l'unicité de chaque produit.
produit. -> exemple diapositive suivante

Convivialité: user friendly

équipes de produit: Product marketing team

34
 SYSTÈMES ET APPAREILS D'INGÉNIERIE OPTIMISÉ

Spécialement Usage
construits général

Exalytics In-Memory

Exadata Exalogic Big Data Database Appliance SPARC SuperCluster

L'expression ultime du matériel et des logiciels conçus pour fonctionner ensemble

est Oracle's Engineered Systems.
Ces systèmes techniques comprennent un ensemble complet de serveurs, de
stockage, de mise en réseau et de logiciels. L’objectif en tant qu'entreprise est
d'ajouter de la valeur aux systèmes matériels pour répondre aux divers besoins des
clients.
Ces machines « spécialement conçues » sont optimisées pour gérer très bien des
types particuliers de charges de travail. Par exemple, si les clients ont besoin d'une
base de données optimisée, ils peuvent utiliser ‘Exadata’; s'ils veulent un
middleware optimisé, ils peuvent l’exécuter sur ‘Exalogic’; s'ils veulent optimiser le
volume, la vitesse et la variété des mégadonnées, ils peuvent utiliser la ‘Big Data
Machine’; s'ils veulent une analyse rapide et des analyses avancées, ils peuvent
utiliser ‘Exalytics In-Memory Machine’.
On a également le SPARC SuperCluster à usage général pour les clients qui
cherchent à consolider différentes charges de travail sur un seul boîtier.
Nous allons discuter plus sur ce type de systèmes dans le cours #8

35
 L'architecture est créée et documentée dans la phase de structuration du système.
 Celle-ci est décomposée en sous-phases, à l'instar de notre modèle d'architecture logicielle:

 Tout d'abord, la vision architecturale est formulée, pour servir de balise guidant les
décisions pendant le reste de la structuration du système.
 C'est une bonne pratique d'allouer explicitement du temps à la recherche sur les styles
architecturaux documentés, les modèles, les conceptions dominantes et les architectures de
référence, les autres architectures que votre organisation, vos concurrents, vos partenaires
ou vos fournisseurs ont créées ou que vous trouvez documentées dans la littérature, etc.

36
 Sur la base de cette étude et de votre expérience passée et de celle de
l'équipe, la méta-architecture est formulée. Cela comprend le style
architectural, les principes, les mécanismes et les concepts qui
guideront l'équipe d'architecture lors des prochaines étapes de structuration.

 Le système est
◦ décomposé en parties et
◦ les responsabilités de chaque composante et
◦ les interconnexions entre les composants sont identifiées.

37
 L'intention de l'architecture conceptuelle est d'attirer l'attention sur une
décomposition appropriée du système sans plonger dans les détails de la
spécification d’interface et de types d’information.
 De plus, il fournit un véhicule utile pour communiquer l'architecture aux
utilisateurs non techniques, tels que la direction, le marketing, ventes, etc.

38
 Exemple : Cloud - Une nouvelle ère de l'informatique utilitaire
Les trois niveaux de calcul fournis en tant que service via un réseau mondial

• Applications : Logiciel en tant que service - SaaS

• Plateforme : Base de données, Middleware, Analytiques,
Intégration… as a Service – PaaS
• Infrastructure : stockage, calcul et réseau en tant que service -
IaaS

SaaS PaaS IaaS

Copyright © 2015 Oracle and/or its affiliates. All rights reserved. 39

Nous sommes au milieu d'une transition générationnelle du sur site au cloud computing
Il y aura une longue période de coexistence du sur site avec le cloud

39
 L'architecture conceptuelle constitue le point de départ de
l'architecture logique, et est susceptible d'être modifiée, ainsi que
raffinée au cours de la création de l'architecture logique.
 La modélisation du comportement dynamique du système (au
niveau de l'architecture ou des composants) est un moyen utile de
réfléchir et de raffiner les responsabilités et les interfaces des
composants.

Actionable = exploitable, actionnable

40
 BigData
Exemple: Oracle Big Data SQL

Data Reservoir Data Warehouse

Big Data SQL

Cloudera Hadoop Oracle Database

Big Data Discovery In-Memory, Multi-
Oracle NoSQL Oracle Big Data Tenant
Oracle R Advanced Connectors Oracle Industry
Analytics for Hadoop Models
Oracle R Distribution Oracle Advanced
Analytics
Oracle Data Integrator Oracle Spatial &
Graph

Big Data Appliance Exadata

Sources

Copyright © 2014 Oracle and/or its affiliates. All rights reserved.

Oracle |Confidential – Internal/Restricted/Highly Restricted
41

Oracle Big Data SQL est une innovation d'Oracle uniquement disponible sur Oracle Big Data Appliance. Il
s'agit d'une nouvelle architecture pour SQL sur Hadoop, intégrant de manière transparente les données dans
Hadoop et NoSQL avec les données dans Oracle Database. À l'aide d'Oracle Big Data SQL, les
organisations peuvent:
• Combiner des données d'Oracle Database, Hadoop et NoSQL dans une seule requête SQL
• Interroger et analyser des données dans Hadoop et NoSQL
• Intégrer l'analyse de données volumineuses dans les applications et architectures existantes
• Étendre les politiques de sécurité et d'accès à partir de Oracle Database aux données dans Hadoop et
NoSQL
Oracle NoSQL est une sorte de base de données qui n'a pas de schéma fixe comme le fait un SGBDR
traditionnel, de cette façon plus flexible. Hadoop offre aux entreprises un endroit unique pour stocker, traiter
et analyser toutes leurs données nonsructurées ou semi-structurées. Les connecteurs Big Data offrent un
accès haut débit aux données dans Hadoop à partir d'Oracle Exadata et d'Oracle Database, avec des taux
de transfert de données de l'ordre de 15 To/heure. Les connecteurs Big Data permettent également des
analyses intégrées et hautement évolutives, offrant un accès natif aux données Hadoop et un traitement
parallèle à l'aide d'Oracle R Distribution. L'option Oracle Spatial and Graph pour Oracle Database 12c inclut
des fonctionnalités avancées pour les données et l'analyse spatiales ; applications physiques, de réseau et
de graphes sociaux ; et une fondation pour aider les applications commerciales géolocalisées. Oracle Data
Integrator (ODI) est un outil d'extraction, de chargement et de transformation (ELT) (contrairement à
l'approche commune ETL) produit par Oracle qui offre un environnement graphique pour créer, gérer et
maintenir des processus d'intégration de données dans des systèmes de veille économique.

41
 La spécification des composants rend l'architecture concrète, telles que
◦ une description sommaire des services fournis par le composant,
◦ le nom du propriétaire du composant,
◦ IID et noms de version,
◦ signatures de messages (IDL),
◦ une description des opérations,
◦ contraintes ou pré/post conditions pour chaque opération (celles-ci peuvent être
représentées dans un diagramme d'état),
◦ le modèle de concurrence,
◦ contraintes sur la composition des composants,
◦ un modèle de cycle de vie, comment le composant est instancié, et nommé,
◦ un scénario d'utilisation typique,
◦ un exemple de programmation, des exceptions et une suite de tests ou de performances

42
 Une architecture d'exécution est créée pour les systèmes distribués/concurrents.
 Il est formé en mappant les composants sur les processus du système physique.
 Différentes configurations possibles sont évaluées par rapport à des exigences telles
que les performances et la mise à l'échelle (scaling).
 À chaque étape de la structuration, il est utile de stimuler la créativité de l'équipe
pour élargir l'ensemble de solutions à l'étude, puis d'évaluer les différentes
alternatives d'architecture par rapport aux exigences architecturales prioritaires.
 Ceci est connu sous le nom d'analyse de compromis d'architecture (Barbacci et.
al., 1998), et il reconnaît que différentes approches produisent différents degrés
d'adéquation aux exigences. La sélection de la meilleure solution implique
généralement un certain compromis, mais il est préférable de le rendre explicite.

43
 Enfin, une phase de validation fournit des indicateurs précoces, et donc
une opportunité de résolution des problèmes d'architecture.

 Lors de la structuration, les architectes s'efforcent évidemment de répondre aux

exigences de l'architecture. La phase de validation de l'architecture implique des
personnes supplémentaires extérieures à l'équipe d'architecture pour aider à fournir
une évaluation objective de l'architecture. En plus de renforcer la confiance dans le
fait que l'architecture répondra aux exigences qui lui sont imposées, l'inclusion des
bons participants à cette phase peut aider à créer l'adhésion à l'architecture.

44
 L'évaluation de l'architecture implique :
◦ «expériences de pensée» *),
◦ la modélisation et parcours des scénarios **) qui illustrent les exigences,
◦ évaluation par des experts qui recherchent les lacunes et les faiblesses de
l'architecture en fonction de leur expérience.
 Une autre partie importante de la validation est le développement
de prototypes ou de preuves de concept (POC - Proof of Concept).
Prendre une version squelettique de l'architecture jusqu'à la mise
en œuvre, par exemple, est un très bon moyen de prouver les
aspects de l'architecture.

*) Une expérience de pensée est une situation hypothétique dans laquelle une
hypothèse, une théorie ou un principe est présenté dans le but de réfléchir à ses
conséquences.
**) Modélisation et le parcours des scénarios: si c'est au tout début du projet, lorsque
l'équipe essaie de parvenir à un consensus sur ce que le produit doit être, une
présentation de scénario peut être une activité d'équipe utile. Il est préférable de le
faire une fois que la personne clé a été identifiée et comprise par l'équipe.

45
 Bien que décrit séquentiellement ci-dessus, le processus d'architecture est
mieux mené de manière itérative, avec plusieurs cycles à travers les
exigences, la structuration et la validation:

Une approche consiste à avoir au moins un cycle consacré à chacune des phases et
cycles d'architecture méta, conceptuelle, logique et d'exécution pour développer les
directives architecturales et tout autre matériel pour aider au déploiement de
l'architecture (tels que des tutoriels). A chaque cycle, juste assez d'exigences sont
collectées pour passer à l'étape de structuration suivante, et la validation se concentre
sur l'architecture dans sa phase actuelle de maturité et de profondeur

46
 De plus, un certain nombre d'équipes d'architecture peuvent s’arrêtées à différents
moments, laissant une architecture plus détaillée aux équipes de produits et de
composants.
 À une extrémité du spectre, une très petite équipe d'architectes a créé la méta-
architecture, et chacune des équipes de produit a créé ses propres architectures en
respectant les directives et les contraintes de la méta-architecture. D'autres
équipes d'architecture ont créé les architectures méta et conceptuelles, et une
équipe plus large de propriétaires de composants a développé l'architecture logique.
 À l'autre extrémité du spectre, l'équipe d'architecture a développé toute
l'architecture, jusqu'à sa spécification détaillée d'architecture logique. Cette
approche donne le plus de contrôle sur la spécification de l'architecture, mais est
généralement confronté de problèmes organisationnels - par exemple, le «syndrome
NIH»*) qui ralentisse ou même inhibe complètement l'utilisation de l'architecture.
*) NIH = Not invented here

*) Pas inventé ici

Not invented here (NIH) est la tendance à éviter d'utiliser ou d'acheter des produits,
des recherches, des normes ou des connaissances d'origine externe. Il est
généralement adopté par les cultures sociales, d'entreprise ou institutionnelles. La
recherche illustre un fort parti pris contre les idées de l'extérieur.

47
 Le processus d'architecture intègre un processus technique et un
processus organisationnel.
◦ Cependant, une bonne architecture technique n'est pas suffisante pour garantir l'utilisation
réussie de l'architecture, et le processus organisationnel est orienté vers la prise en
charge et l'adoption de l'architecture.
 Les projets d'architecture sont sensibles à trois principales sources d'échec
organisationnel :
1. le projet manque de ressources ou est annulé prématurément par une direction non
engagée (non convaincue);
2. il est bloqué par des luttes internes sans fin ou un manque de leadership;
3. l'architecture est ignorée ou résistée par les développeurs de produits.
 Le processus organisationnel aide à surmonter ces problèmes. Deux phases,
Init/Commit et Déploiement, soutiennent le processus technique.

48
 La phase Init/Commit se concentre sur le lancement du projet d'architecture sur des
bases solides et d’obtenir un engagement fort de la part de la haute direction.
 La création de la vision de l'architecture est essentielle à la fois pour aligner l'équipe
d'architecture et pour obtenir le support de la direction.
 Un plan de communication est également utile pour sensibiliser l'équipe à la
nécessité de communiquer fréquemment avec les autres membres de l'organisation.
 Un projet d'architecture discret, de type «skunk works»*, bien caché, peut progresser
rapidement - tant qu'il est bien mené et que ses membres agissent en équipe.
 Cependant, ne pas écouter les besoins de la direction, des développeurs, du
marketing, de la fabrication et des communautés d'utilisateurs et ne pas prêter
attention à l'obtention et au maintien d'un parrainage (soutien) dans la gestion et la
direction technique de l'organisation, ou à l'adhésion de la communauté des
développeurs, conduira à échec.

Le plan de communication met l'accent sur l'équilibre entre le besoin de communication

et l'isolement, ainsi que sur la planification de ce qu'il faut communiquer, quand et à
qui.

*) Skunk Works
Cela semble presque trop beau pour être vrai, mais c'est vrai et les succès sont bien
documentés dans un livre publié en 1994 et écrit par Ben Rich. Ce livre décrit les
nombreuses réalisations - et certains des problèmes - de ce centre d'ingénierie spécial
et hautement secret de Lockheed Aircraft connu sous le nom de "Skunk Works". C'est
le groupe dédié qui a développé et conçu, parmi de nombreux avions, le U-2, le SR 71
(connu pour voler plus vite que trois fois la vitesse du son) et le célèbre chasseur-
bombardier Stealth qui a été un si grand succès dans l’opération ‘Tempête du désert’.
Dans son livre bien écrit, Skunk Works, M. Rich (qui a dirigé l'organisation de 1975 à
1991) décrit les techniques d'ingénierie et de gestion que Skunk Works utilisait dans les
années 60, ce qui est maintenant considéré comme moderne.

49
 La phase de déploiement suit le processus technique et répond aux besoins des
développeurs qui sont censés d’utiliser l'architecture pour concevoir et mettre en
œuvre des produits. Celles-ci vont de la compréhension de l'architecture et de sa
raison d'être, à répondre aux besoins de modifications de l'architecture.
 Cela implique des conseils, et peut-être des tutoriels et des démos, ainsi que
l'implication des architectes dans les revues de conception.
 Il est important qu'au moins l'architecte senior et le chef de projet d'architecture (s'il y
en a un) agissent énergiquement pour l'architecture et obtiennent le soutien de tous
les niveaux de gestion concernés par l'architecture.
 La promotion de l'architecture par le champion commence tôt et se poursuit tout au
long de la vie de l'architecture, bien que l'attention portée à la promotion diminue au
fur et à mesure que l'architecture est adoptée par les communautés de gestion et de
développeurs.

50
 Pour que l'équipe d'architecture réussisse, il doit y avoir un leader et les
membres de l'équipe doivent collaborer pour apporter leur créativité et leur
expérience à la création d'une architecture qui servira au mieux a
l'organisation.
 Cela semble si évident qu'il ne mérite pas d'être dit, mais malheureusement
c'est plus facile à dire qu'à faire. Une attention explicite au développement
des compétences en leadership de l'architecte principal désigné, de la même
manière que l'on s'occuperait de développer ces compétences en gestion,
est un investissement valable.
 De même, investir dans des activités visant à développer les personnes
impliquées en tant qu'équipe a également une grande rentabilité dans
l'efficacité de l'équipe.

Il est important de consulter et d'aider la communauté des développeurs dans

leur utilisation de l'architecture pour faciliter son adoption réussie et son utilisation
appropriée. Ces activités sont plus intenses pendant le déploiement.
Cependant, la communication et le conseil précoces aident à créer l'adhésion de
la communauté des développeurs grâce à la participation et à la compréhension.
Cela permet à l'équipe d'architecture de comprendre les besoins des
développeurs et les développeurs de comprendre l'architecture (et sa logique) à
mesure qu'elle évolue à travers les cycles du processus technique.

51
 Un style architectural dans le développement de logiciels se compose de
quelques fonctionnalités clés et de règles permettant de combiner ces
fonctionnalités afin de préserver l'intégrité architecturale. Un style de logiciel
architectural est déterminé par les éléments suivants :
1. L’ensemble de types de composants (par exemple, un référentiel de données, un
processus, une procédure) qui exécutent certaines fonctions au moment de l'exécution;
2. La disposition topologique de ces composants indiquant leurs interrelations
d'exécution;
3. L’ensemble de contraintes sémantiques (par exemple, un référentiel de données
n'est pas autorisé à modifier les valeurs qui y sont stockées);
4. L’ensemble de connecteurs (par exemple, appel de sous-programme, appel de
procédure à distance, flux de données, sockets) qui assurent la communication, la
coordination ou la coopération entre les composants

52
 Les architectures centrées sur les données ont pour objectif d'atteindre la qualité
d'intégrabilité des données.
 Le terme architecture centrées sur les données fait référence à des systèmes dans
lesquels l'accès et la mise à jour d'un magasin de données largement accessible est une
description appropriée.

 Au fond, ce n'est rien de plus qu'un magasin de données (centralisé) qui communique avec
un certain nombre de clients. Le moyen de communication (parfois appelé modèle de
coordination) distingue les deux sous-types : référentiel (celui représenté) et tableau noir. Un
tableau noir envoie une notification aux abonnés lorsque les données d'intérêt changent, et
est donc actif.

L'architecture orientée données a été décrite pour la première fois par Rajive Joshi
dans un livre blanc de 2007 à RTI, et à nouveau en 2017 par Christian Vorhemus et
Erich Schikuta de l'Université de Vienne dans cet article iiWAS. DOA est une inversion
de la dichotomie traditionnelle entre un binaire monolithique et un magasin de données
(architecture monolithique) d'une part, et de petits binaires distribués et indépendants,
chacun avec ses propres magasins de données (microservices et architecture orientée
services) d'autre part. Dans une architecture orientée données, un magasin de
données monolithique est la seule source d'état du système, sur laquelle agissent des
microservices faiblement couplés et sans état.

53
 Les styles centrés sur les données deviennent de plus en plus
importants car ils offrent une solution structurelle contre l'illisibilité.
De nombreux systèmes, en particulier ceux construits à partir de
composants préexistants, réalisent l'intégration des données grâce à
l'utilisation de mécanismes de tableau noir. Ils ont l'avantage que les
clients sont relativement indépendants les uns des autres et que le
magasin de données est indépendant des clients.
 Ainsi, ce style est évolutif: de nouveaux clients peuvent être
facilement ajoutés. Il est également modifiable en ce qui concerne des
changements de la fonctionnalité de n’importe quel client particulier, car
sinon il ne sera pas affecté. Le couplage entre les clients réduira cet
avantage, mais peut se produire pour améliorer les performances.

Voir l’evolution de DW -> Data Lake -> Delta Lake -> Data Lakehouse -> Data Mesh,
etc.

54
 Example: Systèmes d'ingénierie Oracle pour le Big Data
Big Data
Appliance Exadata Exalytics

ACQUÉRIR ORGANISER ANALYSER DECIDER

55

L'architecture centrée sur les données d'Oracle est cartographiée sur le cycle de vie
des données : acquisition des données, organisation des données, analyse des
données, prise de décision.

55
 Les architectures de flux de données ont pour objectif d'atteindre
les qualités de réutilisation et de modifiabilité.
 Le style de flux de données se caractérise par la visualisation du
système comme une série de transformations sur des éléments
successifs de données d'entrée. Les données entrent dans le
système, puis traversent les composants un par un jusqu'à ce
qu'elles soient affectées à une destination finale (sortie ou magasin
de données).

56
 Dans le style séquentiel par lots, les étapes de traitement, ou
composants, sont des programmes indépendants, et l'hypothèse est
que chaque étape s'exécute jusqu'à la fin avant que l'étape suivante
ne commence. Chaque lot de données est transmis dans son
ensemble entre les étapes.
 L'application typique de ce style est le traitement de données
classique

57
  Le style Tuyaux et Filtre met l'accent sur la transformation
incrémentielle des données par composants successifs. Il s'agit
d'un style typique de la famille des systèmes d'exploitation UNIX

Ce modèle peut être utilisé pour structurer des systèmes qui produisent et traitent un
flux de données. Chaque étape de traitement est enfermée dans un composant de
filtre. Les données à traiter passent par des tuyaux. Ces canaux peuvent être utilisés
pour la mise en mémoire tampon ou à des fins de synchronisation.
Usage
• Compilateurs. Les filtres consécutifs effectuent une analyse lexicale, une analyse
syntaxique, une analyse sémantique et une génération de code.
• Flux de travail en bio-informatique.

58
 Les filtres sont des transducteurs de flux. Ils transforment progressivement les
données (flux par flux), utilisent peu d'informations contextuelles et ne conservent
aucune information d'état entre les instanciations. Les tuyaux sont sans état et
existent simplement pour déplacer des données entre les filtres.
 Les tuyaux et les modifications sont exécutés de manière non déterministe
jusqu'à ce qu'il n'y ait plus de calculs ou de transmissions possibles. Les contraintes
du style indiquent les façons dont les tuyaux et les filtres peuvent être joints.
 Un tuyau a une extrémité source qui ne peut être connectée qu'au port de sortie d'un
filtre et une extrémité d’évier (sink) qui ne peut être connectée qu'au port d'entrée
d’un filtre.
 Les systèmes de tuyaux et filtres, comme tous les autres styles, présentent un
certain nombre d'avantages et d'inconvénients.
 Leurs avantages découlent principalement de leur simplicité - les moyens limités
dont ils peuvent interagir avec leur environnement.

Exemples: SPARQ, KAFKA.

59
 Le style tuyau et filtre simplifie la maintenance du système et
améliore la réutilisation pour la même raison: les filtres sont
autonomes et nous pouvons les traiter comme des boîtes noires.
 Les tuyaux et les filtres peuvent être composés hiérarchiquement :
◦ Toute combinaison de filtres, reliés par des tuyaux, peut être emballée et
apparaître au monde extérieur comme un filtre.
 Parce qu'un filtre peut traiter son entrée indépendamment du reste
du système, un système de tuyaux et de filtres est facilement mis en
parallèle ou distribué, offrant des possibilités d'améliorer les
performances d'un système sans le modifier.

60
 Il n'y a aucun moyen pour les filtres d'interagir de manière coopérative
pour résoudre un problème. Les performances d'un tel système sont souvent
médiocres pour plusieurs raisons, qui découlent toutes de l'isolation des
fonctionnalités qui rendent les tuyaux et les altérations si modifiables; ces
raisons sont énumérées ci-dessous :
◦ Les filtres forcent généralement le plus petit dénominateur commun de la représentation
des données (par exemple un flux ASCII, ou JSON). Si le flux d'entrée doit être transformé
en jetons (token), chaque filtre paie cette surcharge d'analyse / désanalyse.
◦ Si un filtre ne peut pas produire sa sortie tant qu'il n'a pas reçu toutes ses entrées, il aura
besoin d'un tampon d'entrée de taille illimitée. Un filtre de triage est un exemple de
filtre qui souffre de ce problème. Si des tampons bornés sont utilisés, le système pourrait
se bloquer.
◦ Chaque filtre fonctionne comme un appel de processus ou de procédure distinct,
entraînant ainsi une surcharge à chaque fois qu'il est invoqué.

61
 Les architectures de machines virtuelles ont pour objectif d'atteindre la qualité de la
portabilité.
 Les machines virtuelles sont des styles logiciels qui simulent certaines
fonctionnalités qui ne sont pas natives du matériel et/ou du logiciel sur lequel elles
sont implémentées.
 Cela peut être utile de plusieurs façons: • Il peut permettre de simuler (et de tester)
des plates-formes qui n'ont pas encore
été construites (comme un nouveau
matériel), et il peut simuler des modes
"désastre" (comme c'est courant dans les
simulateurs de vol et les systèmes
critiques pour la sécurité) qui seraient trop
complexes, coûteux ou dangereux à
tester avec le système réel.
• Des exemples courants de machines
virtuelles sont les interpréteurs, les
systèmes basés sur des règles, les
coques syntaxiques et les processeurs de
langage de commande

Exemples: VMWARE, OVM (Oracle Virtual Machine)

62
 L'interprétation d'un module particulier via une machine virtuelle peut
être vue comme suit:
◦ le moteur d'interprétation sélectionne une instruction du module en cours
d'interprétation;
◦ sur la base de l'instruction, le moteur met à jour l'état interne de la machine
virtuelle;
◦ le processus ci-dessus est répété;
 L'exécution d'un module via une machine virtuelle ajoute de la
flexibilité grâce à la possibilité d'interrompre et d'interroger le
programme et d'introduire des modifications au moment de
l'exécution, mais il y a un coût de performance en raison du calcul
supplémentaire impliqué dans l'exécution

63
 Les architectures d'appel et de retour (Call-and-return) ont
pour objectif d'atteindre les qualités de modifiabilité et de
solvabilité.
 Les architectures d'appel et de retour ont été le style
architectural dominant dans les grands systèmes logiciels au
cours des 40 dernières années.
 Cependant, dans ce style, un certain nombre de sous-styles,
dont chacun a des caractéristiques intéressantes, ont
émergé.

64
 Les architectures de programmes principaux et de sous-programmes
constituent le paradigme de programmation classique. L'objectif est de
décomposer un programme en plus petits morceaux pour aider à atteindre la
possibilité de modifiabilité.
 Un programme est décomposé hiérarchiquement. Il existe généralement un
seul fil de contrôle et chaque composant de la hiérarchie obtient ce contrôle
(éventuellement avec certaines données) de son parent et le transmet à ses
enfants..

65
 Les systèmes RPC sont des systèmes de programmes principaux et de
sous-programmes qui sont décomposés en parties qui vivent sur des
ordinateurs connectés par un réseau.
 L'objectif est d'augmenter les performances en répartissant les calculs et
en tirant parti de plusieurs processeurs. Dans les systèmes d'appel de
procédure à distance, l'affectation réelle des parties aux processeurs est
retardée jusqu'à l'exécution, ce qui signifie que l'affectation est facilement
modifiée pour s'adapter au réglage des performances.
 En fait, sauf que les appels de sous-programmes peuvent prendre plus de
temps à s'accomplir s'ils invoquent une fonction sur une machine distante, un
appel de procédure à distance est indiscernable des programmes principaux
standard et des systèmes de sous-programmes.

66
 Les systèmes de type orientés objet, ou de données abstraites, sont la version
moderne des architectures d'appel et de retour.
 Le paradigme orienté objet, comme le paradigme du type de données abstrait à
partir duquel il a évolué, met l'accent sur le regroupement de données et de
méthodes pour manipuler et accéder à ces données (par une interface publique).
 Les abstractions d'objets forment des composants qui fournissent des services de
boîte noire et d'autres composants qui demandent ces services.
 L'objectif est d'atteindre la qualité de modifiabilité.

• Le groupage représente dans la diapo est une encapsulation qui cache ses
secrets internes à son environnement. L'accès à l'objet est autorisé uniquement
via les opérations fournies, généralement appelées méthodes, qui sont des formes
contraintes d'appels de procédure.
• Cette encapsulation favorise la réutilisation et la possibilité de modification,
principalement parce qu'elle favorise la séparation des préoccupations : l'utilisateur
d'un service n'a pas besoin de savoir et ne devrait rien savoir de la façon dont ce
service est mis en œuvre..

67
La diapo presente troix manieres d’architecture client/serveur.

Ex. 1 utilise le protocole HTTP pour passer des pages HTML entre le client et le
serveur qui contient la base de donnees.

Ex. 2 utilize JSP (Java Server Pages).

Ex. 3 utilize un service de type RESTful.

68
  Les systèmes en couches sont ceux dans lesquels les composants
sont affectés à des couches pour contrôler l'interaction entre les
composants. Dans la version pure de cette architecture, chaque
niveau ne communique qu'avec ses couches voisins immédiats
 L'objectif est d'atteindre les qualités de modifiabilité et
généralement de portabilité.
• La couche la plus basse fournit
certaines fonctionnalités de base,
telles que :
• matériel, ou
• noyau système d'exploitation.
• Chaque couche successive est
construite sur son prédécesseur,
masquant la couche inférieure et
fournissant certains services que
les couches supérieures utilisent.

Ce modèle peut être utilisé pour structurer des programmes qui peuvent être
décomposés en groupes de sous-tâches, dont chacune se trouve à un niveau
d'abstraction particulier. Chaque couche fournit des services à la couche supérieure
suivante.
Les 4 couches les plus courantes d'un système d'information général sont les suivantes.
1. Couche de présentation (également appelée couche d'interface utilisateur)
2. Couche d'application (également appelée couche de service)
3. Couche de logique métier (également appelée couche de domaine)
4. Couche d'accès aux données (également appelée couche de persistance)
Usage
• Applications de bureau générales.
• Applications Web de commerce électronique.

69
Exemple : Les trois couches du cloud Oracle
conçues pour fonctionner ensemble
Applications, plateforme et infrastructure intégrées… Jusqu'au silicium

CX Suite ● HCM Suite ● ERP Suite ● EPM Suite ● SCM Suite ●

Data Suite
Oracle Cloud Applications

Data Management ● Application Development ● Integration ● Mobile

Content and Process ● Business Analytics ● Identity Management ● IT
Operations Management
Oracle Cloud Platform

Compute ● Storage ● Network

Oracle Cloud Infrastructure

Faible coût, fiabilité, performances, normes, compatibilité, sécurité

intégrée aux trois couches
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. 70

70
 Les architectures de composants indépendants consistent en un certain nombre de
processus ou d'objets indépendants qui communiquent par le biais de messages.
 Toutes ces architectures ont pour but d'atteindre la modifiabilité en découplant différentes
parties des calculs. Ils s'envoient des données mais ne se contrôlent généralement pas
directement (Voir SOA – Services Orriented Architecture)
 Les messages peuvent être transmis à :
◦ participants nommés (style de communication de processus);
◦ participants anonymes utilisant le paradigme de publication/abonnement (style de systèmes
d'événement, diapositive suivante)

71
 Les systèmes d'événements sont un sous-style dans lequel le contrôle fait
partie du modèle. Les composants individuels annoncent les données qu'ils
souhaitent a partager (publier) avec leur environnement - un ensemble de
composants sans nom.
 Ces autres composants peuvent enregistrer un intérêt pour cette classe de
données (s'abonner). S'ils le font, lorsque les données apparaissent, ils sont
invoqués et reçoivent les données

72
 En règle générale, les systèmes d'événements utilisent un gestionnaire de messages qui
gère la communication entre les composants, appelant un composant (le contrôlant ainsi)
lorsqu'un message arrive pour lui.
 Dans ce paradigme de publication/abonnement, un gestionnaire de messages peut contrôler
ou non les composants auxquels il transfère les messages.
 Les composants enregistrent les types d'informations qu'ils sont prêts à fournir et qu'ils
souhaitent recevoir.
 Alors, ils publient des informations en les envoyant au gestionnaire de messages, qui
transmet le message, ou dans certains cas une référence d'objet, à tous les participants
intéressés.
 Ce paradigme est important car il dissocie les implémentations de composants de la
connaissance des noms et emplacements des autres.
 Comme mentionné, cela peut également impliquer le découplage du contrôle, ce qui signifie
que les composants peuvent fonctionner en parallèle, n'interagissant que par un échange de
données lorsqu'ils le souhaitent. Ce découplage facilite l'intégration des composants.

73
 Outre les systèmes d'événements, l'autre sous-style de composants
indépendants est le style des processus communicants. Ce sont
les systèmes multi procès classiques.
 Parmi ceux-ci, le client-serveur est un sous-type bien connu.
L'objectif est d'atteindre la qualité d'évolutivité.

• Un serveur existe pour fournir des données à un ou plusieurs clients, qui sont
généralement situés sur un réseau.
• Le client lance un appel au serveur, qui fonctionne, de manière synchrone ou
asynchrone, pour répondre à la demande du client.
• Si le serveur fonctionne de manière synchrone, il rend le contrôle au client en
même temps qu'il renvoie les données. Si le serveur fonctionne de manière
asynchrone, il ne renvoie que des données au client (qui a son propre flux de
contrôle)

74
 Les systèmes sont rarement construits à partir d'un style unique, et nous
disons que de tels systèmes sont hétérogènes.
 Il existe trois types d'hétérogénéité, ils sont les suivants.
1. Localement hétérogène signifie qu'un dessin de ses structures d'exécution révélera
des modèles de styles différents dans différentes zones.
 Par exemple, certaines branches d'un système Programme principal et de sous-programmes
peuvent avoir un référentiel de données partagé (c'est-à-dire une base de données)

75
2. Hiérarchiquement hétérogène signifie qu'un composant d'un style,
lorsqu'il est décomposé, est structuré selon les règles d'un style différent.
◦ Par exemple, un sous-système d'interface utilisateur final peut être construit en utilisant le
style architectural du système d'événements, tandis que tous les autres sous-systèmes -
en utilisant l'architecture en couches

76
3. Simultanément hétérogène signifie que n'importe lequel de plusieurs
styles peut très bien être une description appropriée du système.
◦ Cette dernière forme d'hétérogénéité reconnaît que les styles ne divisent pas les
architectures logicielles en catégories pures et sans chevauchement. Vous l'avez peut-
être déjà remarqué.
 Le style centré sur les données au début de cette discussion était composé de clients
indépendants des threads, un peu comme une architecture de composants indépendants.
 Les couches d'un système en couches peuvent comprendre des objets ou des composants
indépendants ou même des sous-programmes dans un système de programme principal et de
sous-programmes.
 Les composants d'un système de tuyaux et de filtres sont généralement mis en œuvre en tant
que processus qui fonctionnent indépendamment, attendant que l'entrée soit à leurs ports,
encore une fois, cela est similaire aux systèmes de composants indépendants dont l'ordre
d'exécution est prédéterminé

77