Modèles dans l’architecture logicielle : le modèle en couches

Les modèles sont une abstraction importante dans le développement de logiciels modernes et l’architecture logicielle. Ils offrent une terminologie bien définie, une documentation propre et l’apprentissage des meilleurs. Le modèle en couches divise une tâche en couches horizontales. Chaque couche a une responsabilité spécifique et fournit un service à la couche supérieure.

Le motif en couches ou architecture en couches est un motif architectural qui, selon le livre “Architecture logicielle orientée modèle, volume 1” contribue à structurer le chaos.

Aussi connu sous le nom

But

• Gros systèmes qui doivent être démontés

Problème

• Un système qui effectue des opérations à différents niveaux,
• les niveaux supérieurs utilisent les niveaux inférieurs

Solution

• Structurer le système en couches,
• les services de niveau supérieur sont basés sur les services de niveau inférieur.

Structure

Client

• Accède au niveau supérieur

Layer J

• résume le rôle et la responsabilité spécifiques du Layer J,
• offre ses services en utilisant le Layer J-1 sur et
• ne peut que monter Layer J-1 accès.

Bien que cela ne soit pas spécifié, la plupart des architectures en couches se composent de trois ou quatre couches. Chaque couche est indépendante des autres. Dans la version pure, une couche ne peut accéder qu’à celle qui se trouve en dessous. Une couche ne peut pas accéder à sa couche supérieure car cela créerait des dépendances supplémentaires et compliquerait la structure de contrôle. De plus, une couche qui dépend d’une couche supérieure ne peut pas facilement être utilisée dans une autre application. Une couche fournit souvent ses fonctions en implémentant le motif de façade prêt. Le motif Façade fournit une interface simplifiée à un système complexe.

exemples

Le modèle en couches a été largement utilisé depuis les premiers jours du développement logiciel. En conséquence, il existe de nombreux cas d’utilisation :

Modèle OSI et modèle TCP/IP

Le modèle d’interconnexion de systèmes ouverts (modèle OSI) est un modèle conceptuel qui «fournit une base commune pour la coordination des [ISO] l’élaboration de normes aux fins de l’interconnexion des systèmes».[2] Dans le modèle de référence OSI, les communications entre un système informatique sont divisées en sept couches d’abstraction différentes : physique, liaison de données, réseau, transport, session, présentation et application. (https://en.wikipedia.org/wiki/OSI_model)

Il en va de même pour le modèle TCP/IP simplifié : La suite de protocoles Internet, communément appelée TCP/IP, est un cadre permettant d’organiser l’ensemble des protocoles de communication utilisés dans Internet et les réseaux informatiques similaires selon des critères fonctionnels. Les protocoles fondamentaux de la suite sont le protocole de contrôle de transmission (TCP), le protocole de datagramme utilisateur (UDP) et le protocole Internet (IP). (https://en.wikipedia.org/wiki/Internet_protocol_suite)

Système embarqué

Ceux qui développent des logiciels pour les systèmes embarqués utilisent généralement différents niveaux d’abstraction en C++.

• Tu commences généralement par ça Forfait d’assistance au conseil d’administration (BSP) qui contient des configurations spécifiques à la carte telles que le micrologiciel de démarrage et les pilotes de périphérique pour permettre au système d’exploitation intégré de fonctionner.
• Le Couche d’abstraction matérielle (HAL) est situé au-dessus du BSP. Il s’agit d’une couche d’abstraction entre le matériel et le logiciel s’exécutant sur le système embarqué. Son travail consiste à masquer les différences entre le matériel et le système d’exploitation.

Étendre/intégrer Python dans C/C++

L’extension de Python en C/C++ comprend les étapes suivantes :

1. Convertir des valeurs de Python en C/C++,
2. utiliser les valeurs converties pour exécuter la fonctionnalité C/C++ et
3. convertir les résultats de C/C++ en Python.

L’intégration fait la même chose dans l’ordre inverse. Quelle est la prochaine étape sur les couches Python et C ? Voici la stratégie simplifiée.

Tous les types de données Python comme int hériter de object.

L’équivalent C du type de données object est la structure C PyObject. C n’est pas orienté objet. PyObject est une sorte de point de départ pour le stockage d’objets Python. L’implémentation peut être trouvée sur GitHub : objet.c. PyObject a essentiellement un compteur de références et un pointeur vers le type approprié.

Lorsque vous appelez une méthode sur un type Python, cet appel va à la structure C PyObjectdans le object.c est défini. Dans object.c détermine la fonction C Py_TYPE le type de l’objet et appelle la fonction appropriée sur la couche C. Cela signifie que si la méthode correspondante est implémentée sur le type dérivé, elle sera appelée. Sinon, l’implémentation par défaut de PyObject appelé si possible.

Avantages et inconvénients

Avantages

Chaque couche a un rôle spécifique et des tâches spécifiques. Il propose ses services à la couche supérieure via une interface. La couche supérieure ne dépend que de l’interface de la couche inférieure. Par conséquent, la couche inférieure peut être facilement remplacée.

Chaque couche a ses services encapsulés. Cela facilite le test de la fonctionnalité de chaque couche. Au sein des couches, des tests plus fins tels que des tests unitaires doivent être effectués.

Grâce à la séparation des différentes couches (séparation des préoccupations), chaque couche peut être implémentée de manière isolée. Tout d’abord, l’interface entre les couches doit être définie.

Désavantages

• Granularité de la couche

Trouver la bonne granularité de couche peut être un défi. Trop de couches peuvent entraîner des couches avec une responsabilité minimale. De plus, l’architecture peut être difficile à comprendre. Trop peu de couches, il est assez compliqué de remplacer les couches, de les tester et de développer de manière isolée.

Un appel client déclenche une série d’appels qui aboutissent à la couche inférieure. Cette séquence d’appels peut avoir un impact négatif sur les performances de l’application. Cela est particulièrement vrai lorsque les quarts de travail sont éloignés.

Et après?

Le modèle Pipes and Filters est très pratique lorsque vous avez un système qui traite les données en plusieurs étapes et que vous souhaitez que chaque étape soit développée indépendamment. J’en parlerai dans mon prochain article.

(rme)