support easyline stone ristoo finder otelo
Un patron d’architecture[1] logicielle permet de diviser le code pour répondre à des problèmes spécifiques. Il facilite le développement, la maintenance en structurant l’ensemble. C’est une vision globale de la structure du logiciel à concevoir.
Les patrons d’architecture ne doivent pas être confondus avec les patrons de conception[2] dédiés à la résolution d’un problème en décrivant l’organisation de modules et de classes. Les patrons de conception permettent la description d’objets coopératifs et de classes spécialisées pour résoudre un problème général de conception dans un contexte particulier.
On peut les comparer à des composants logiques décrits indépendamment d’un langage donné. Un modèle de conception est une vision plus abstraite qu’un composant. Il serait par exemple inopportun d’utiliser les design patterns pour coder des listes chaînées ou des tables de hachage. Le design pattern n’est pas non plus une représentation complexe spécifique à un domaine : ils ne seront pas utilisés pour coder deux logiciels de facturation qui paraissent analogues dans une entreprise. Leur critère de couverture est donc générique (réutilisables pour un ensemble de problèmes généraux de conception).
Ces patrons répondent à des préoccupations locales. On peut citer comme exemple de patron de conception : singleton, observer, factory, dao[3].
Les patrons d’architectures agrègent l’utilisation de certains Design Pattern. La distinction reste toutefois difficile à établir. Les patterns d’architecture permettent de structurer des schémas d’organisation fondamentaux pour les logiciels intégrés dans un Système d’Information. Ils reflètent la structure générale d’un Système d’Information en sous-systèmes. Parmi les patterns architecturaux, on peut citer le blackboard (architecture avec des modules spécialisés qui partagent leurs connaissances pour construire une solution), le broker (architecture distribuée autour d’un composant de routage des requêtes) et le MVC (Model-View-Controler, architecture qui sépare les Vues externes, les Modèles applicatifs, et les Contrôleurs qui lient les événements sur les vues et les services sur les objets). Leur critère de couverture est générique et ils portent le plus souvent sur la conception des logiciels.
Le MVC a été développé pour SmallTalk à la fin des années 70 pour la construction d’interfaces graphiques. Ce modèle est utilisé dans le Xerox Star. Le modèle MVC agrège les trois design patterns Observateur, Composite et Stratégie. C’est un langage de patterns qui décrit les relations entre les patterns et la façon dont ils peuvent être combinés et composés pour résoudre des problèmes plus complexes. Un langage de patterns est une collection structurée de patterns, ici de patterns de conception, comprenant des règles pour les combiner dans un style architectural.
Les patrons architecturaux sont très utilisés par les architectes des SI. Logiquement, c’est à eux que revient la prise des décisions dans les entreprises pour tel ou tel choix d’architecture technique en cohérence avec la politique mise en place par leurs directions des systèmes d’information. La mise en œuvre d’un SI avec une architecture précise permet de créer et maintenir un cadre unifié, cohérent et évolutif, pour les ressources et les services qui supportent les processus métiers de l’entreprise.
Pour aller plus loin :
- les patrons d’architecture : http://masig.ensg.eu/PDF/Patrons%20d’architecture.pdf
- les différents patrons de conception : https://fr.wikipedia.org/wiki/Patron_de_conception
- Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design patterns, catalogue de modèles de conception réutilisables. Vuibert, 1999.
Un patron d’interaction entre composants, l’architecture client-serveur
L’architecture client-serveur est un patron d’interaction entre composants. L’architecture n-tiers est une des architectures client-serveur.
On définit la notion de « tiers » par une entité client ou serveur séparée par le réseau.
Nous avons donc plusieurs répartitions possibles de 2 à n-tiers.
Présentation de l’architecture à 2 niveaux
L’architecture 2-tiers correspond à une répartition client/serveur. Le client-utilisateur demande un service au serveur. Celui-ci aura la capacité de réaliser le service sans avoir besoin d’autres ressources. Il possède tous les éléments pour le réaliser (serveur d’application, de base de données, etc.).
L’architecture physique peut être représentée par deux machines, le client (un ordinateur ou un smartphone par exemple) et un serveur de base de données (une machine virtuelle avec SQL Server installé ou un serveur MySQL installé en local sur la machine par exemple) :
Au niveau applicatif, le serveur est considéré comme un composant logiciel :
Présentation de l’architecture à 3 niveaux
Dans cette architecture 3-tiers, le serveur ne peut réaliser tous les services sans faire appel à un second serveur spécialisé. Ce second serveur spécialisé est généralement un serveur de gestion de base de données, mais rien n’empêche qu’il soit aussi un serveur d’application.
Le serveur d’application qui réceptionne la demande du client va donc être au milieu des interactions.
Il y a donc 3 serveurs à installer (tiers)
Le niveau 1 correspond au client final : ses échanges avec le niveau 2 sont de type client/serveur pour lequel il joue l’unique rôle de client
Le niveau 2 joue deux rôles, celui de serveur (http) dans ses échanges avec le client final mais de client dans ses échanges avec le niveau 3. C’est le runtime d’execution qui communique avec le back office.
Le niveau 3 joue le rôle de serveur et n’a qu’un seul client, le serveur médian (http et php par exemple).
La spécialisation des serveurs dans chaque tâche permet d’optimiser les ressources et les accès. Il sera donc plus facile de sécuriser les échanges et d’améliorer la performance (QOS, redondance, etc.).
On classifie aussi les clients finaux selon trois catégories :
- client léger : le client ne fait qu’afficher la réponse du serveur, l’application est uniquement coté serveur ;
- client lourd : le traitement est réparti entre le client et le serveur ;
- client riche : le client reçoit une réponse nécessitant peu de traitement mais est capable de la finaliser et de la présenter.
Évolution de la répartition entre client et serveur
La nette augmentation des performances des navigateurs a permis de modifier la répartition des services fournis entre client et serveur d’applications.
Le client peut maintenant gérer l’affichage. Il ne demande plus les pages HTML et le CSS correspondant au serveur mais seulement les données qu’il nécessite.
Dans un premier temps, l’interface homme machine (IHM) était totalement générée par le serveur d’application. Quelques scripts JavaScript permettaient d’optimiser les traitements de l’interface en local par le navigateur. L’ajout d’API orientées réseaux en Javascript a permis de proposer un nouveau langage, Ajax[4]. Il fournit au navigateur la possibilité de gérer une partie de l’affichage grâce à la réception de données brutes issues du serveur web, souvent en XML[5]. Le transport est effectué grâce au protocole applicatif http, et aucun service supplémentaire n’est nécessaire sur le serveur médian.
Actuellement, les navigateurs peuvent gérer l’ensemble de l’affichage en recevant des données brutes majoritairement sous JSON[6] par l’intermédiaire d’un langage comme PHP ou JavaScript. On peut citer Eclipse Orion qui propose un IDE via le navigateur.
Source : OCTO Technology
C’est l’amélioration de la vitesse d’exécution de JavaScript sur les navigateurs qui a permis cette évolution.
Un patron d’interface utilisateur, le MVC
Le modèle MVC
Ce pattern Modèle-vue-contrôleur[7], mis en œuvre à son origine dans des applications de type desktop, répartit le code en trois ensembles.
Le modèle contient le code qui permet d’accéder au SGBDR. Toute requête SQL devra se faire dans cet ensemble. Dans le cas de SGBD NoSQL[8], les accès se feront aussi via cet ensemble. Le modèle permet une plus grande modularité en cas d’évolution ou changement de SGBD.
La vue regroupe toutes les pages visibles. Elle a pour rôle de présenter les données transmises par le contrôleur. Elle doit aussi recevoir les actions de l’utilisateur mais ne doit effectuer aucun traitement. Tout code HTML sera donc dans cet ensemble. Elle a la possibilité de lire des données directement du modèle.
Le contrôleur reçoit les demandes des utilisateurs sous forme d’évènements. Si nécessaire il fera appel au modèle pour modifier les informations. Il a la charge d’appeler les vues à transmettre au client.
- Modèle : il est chargé de la logique de représentation des données qui vont être utilisées dans la vue.
- Vue : Il affiche les données à l’utilisateur. La vue appelle les méthodes du contrôleur en fonction des actions de l’utilisateur. La vue se synchronise avec le modèle pour modifier son affichage en cas de changement d’état du modèle.
- Contrôleur : Le contrôleur est appelé par la vue. Il met à jour le modèle. Il n’a pas connaissance des changements du modèle qui vont interagir sur la vue. Il n’est donc pas responsable de la mise à jour de la vue.
Certaines architectures MVC répondant à des besoins spécifiques peuvent modifier les échanges présentés ci-dessus, notamment entre le modèle et la vue. Les patrons suivants seront des dérivés de MVC. On parle ainsi de modèle MV* pour regrouper tous les dérivés de ce patron.
On sépare le code en trois parties.
Le modèle contiendra le code permettant d’accéder aux SGBD. Toutes requêtes SQL ou équivalent doit donc être dans le modèle.
La vue contiendra les pages qui seront affichées à l’utilisateur. Aucune page des autres modules ne devra s’afficher.
Le contrôleur sert d’aiguillage. Il reçoit la demande de l’utilisateur, appelle le modèle si nécessaire et appelle la vue à transmettre au client.
Quand on réalise une application avec l’architecture MVC, il faut que toutes demandes de l’utilisateur passent par le contrôleur. Aucun affichage ne sera généré par le contrôleur ou le modèle.
Exemple d’architecture MVC
Le contrôleur
c_monControleur.php
<?php session_start();
if (isset($_REQUEST["maVar"])) {
$maVar = $_REQUEST["maVar "];
switch ($maVar) {
case "maPage1":
require_once "../vues/v_maVue1.php";
break;
case "maPage2":
require_once "../modeles/m_monModele1.php";
//insertion d"une liste de fonctions de m_monModele
$mesClients = listeClients();
//valorisation de la variable $mesClients grâce à une fonction
require_once "../vue/v_maVue2.php";
//utilisation de $mesClients dans la vue
break;
}
} else {
require_once "../vue/v_acceuil.php";
}
Le modèle
m_monModele1.php
Le modèle contient plusieurs fonctions
<?php
function connexion()
{
$dsn = "pgsql:host=192.168.1.14;port=5432;dbname=maBase";
try {
return $dbh = new PDO($dsn, " root ", " ");
} catch (PDOException $e) {
}
}
function listeClients()
{
$connexion = connexion();
$sql = " SELECT nom, prenom FROM client ";
$statement = $connexion->query("$sql") or die(print_r($connexion->errorInfo(), true));
$array = array();
foreach ($statement->fetchAll(PDO::FETCH_OBJ) as $ligne) {
array_push($array, $ligne);
}
$statement->closeCursor();
return $array;
}
La vue
v_maVue2.php
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<title>mon titre</title>
</head>
<body>
<?php
print("<select name=’maListe’ size=’1’>");
foreach ($mesClients as $client){
print("<option>". $client->prenom ."</option>");
}
print("</select>");
?>
</body>
</html>
On réutilise la variable du modèle passée au contrôleur, accessible à la vue grâce aux inclusions de pages PHP
v_acceuil.php
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>mon titre</title>
</head>
<body>
<form method="post" id="frmConnection" action="recuperation.php?maVar=maPage2">
<label for="email"> Votre email:</label>
<input type="email" name="txtEmail" id="txtEmail" autofocus />
</br>
<label for=" txtPass "> Mot de passe :</label>
<input type="password" name="txtPass" required />
<input type="submit" name="cmd" id="cmd" value=" envoie " />
</form>
</body>
</html>
MVC2, un nouveau modèle ?
MVC2 n’est pas une nouvelle architecture à proprement parler. C’est une implémentation spécifique de MVC lancée par SUN[9] pour répondre à une évolution de ses applications web. Elle impose un seul et unique contrôleur pour réceptionner les demandes du client. Il n’y a plus qu’un contact unidirectionnel entre la vue et le modèle. Le modèle n’informe plus la vue d’un quelconque changement.
Source : Manoj Jaggavarapu
MVC2 est un modèle MVC adapté pour le web.
Le modèle MVP ou MVA
Ce modèle est dérivé du MVC et peu utilisé.
Le pattern MVC nécessite que le modèle communique les changements à la vue. La vue connait parfaitement le modèle et se synchronise avec celui-ci pour connaitre ses changements. Elle n’est donc pas passive.
Le patron modèle-vue-présentateur[10] ou modèle-vue-adaptateur[11] permet d’éviter les échanges entre la vue et le modèle. Plusieurs vues peuvent accéder indirectement au même modèle par l’intermédiaire de l’adaptateur. La vue ne connait pas le modèle et n’y a jamais accès. Le modèle ne connait pas comment les données seront exploitées par la vue.
Le présentateur est responsable du changement de la vue en cas de modification des données contrairement au contrôleur.
Il peut exister plusieurs adaptateurs pour un couple vue-modèle répondant chacun à une logique d’interprétation des données. Par exemple, une même base de données, avec une même vue peut présenter des informations différentes selon l’adaptateur utilisé. L’adaptateur peut être choisi par géolocalisation, par action de l’utilisateur, etc.
- Modèle : il représente les objets métiers ;
- Présentateur ou adaptateur : Contrairement au contrôleur, le présentateur peut mettre à jour la vue et présenter les actions utilisateurs au modèle qui sera chargé d’agir en fonction de ces actions. Il interagit également avec la vue sous forme de contrat[12].
- Vue : La vue ne doit gérer que l’interface et être avertie des changements du modèle.
Deux catégories de MVP selon le rôle de la vue :
La vue passive
La vue ne connait pas le modèle.
Source : Manoj Jaggavarapu
La vue active
La vue utilise la notion de Data Binding[13] pour se mettre à jour. Elle connait donc le modèle.
Source : Manoj Jaggavarapu
Le modèle PM
Le patron présentation-modèle[14] répond à une avancée des interfaces utilisateurs. Il a été développé par Martin Fowler. On nomme ces interfaces rich UI car elles permettent de synchroniser automatiquement des informations entre la vue et le présentateur.
La vue modèle a la responsabilité de convertir les données du modèle pour qu’elles soient facilement utilisables et présentables.
Source : Manoj Jaggavarapu
- Modèle : le modèle représente l’état de la vue et non l’objet métier. Il peut contenir des éléments spécifiques de l’interface utilisateur. Il y a donc une forte dépendance entre la vue et le modèle.
- Vue : La vue ne gère que l’affichage. Les actions de l’utilisateur sont transmises au présentateur qui modifie directement le modèle. Une fois le modèle modifié, le présentateur rafraichit la vue.
- Présentateur : Il a les mêmes rôles que dans le modèle MVP mais il héberge l’objet métier. Il est responsable de sa mise à jour et de lancer l’action de rafraichissement de la vue. Il communique avec la couche métier[15]. La logique applicative est donc fortement déplacée et n’est plus la principale préoccupation de ce patron qui se concentre sur la couche présentation.
Le modèle MVVM
Le patron modèle vue vue-modèle[16] est une variation du modèle PM développé par John Gossman, architecte chez Microsoft.
La vue-modèle implémente le patron de conception médiateur[17] pour éviter le couplage avec le modèle. La vue-modèle est responsable de la logique d’interprétation des données pour la vue et de sa mise à jour en cas de changement des données du modèle.
La vue est étroitement liée à la vue-modèle par un mécanisme de Data Binding. Les données sont synchronisées entre ces deux ensembles sans intervention explicite du développeur.
Source : Microsoft
- Vue : similaire au modèle PM avec la notion de Data Binding ;
- Vue-modèle : similaire au présentateur ;
- Modèle : similaire au Business logic layer du modèle PM.