Chapitre 4 : Architecture & Conception de logiciels

<!-- Slide number: 19 --> # Découpage en couches – Modèle en 3 couches 19 Couche infrastructure :

Est la partie du code responsable de l'accès aux données dans une application multiniveau doit être encapsulée dans une couche dédiée aux interactions avec la base de données de l'architecture.

Celle-ci permet notamment : d'ajouter un niveau d'abstraction entre la base de données et l'utilisation qui en est faite. de simplifier la couche métier qui utilise les traitements de cette couche de masquer les traitements réalisés pour mapper les objets dans la base de données et vice versa de faciliter le remplacement de la base de données utilisée

La couche métier qui va utiliser la couche infrastructure reste indépendante du code dédié à l'accès à la base de données. Ainsi la couche métier ne contient aucune requête SQL, ni code de connexion ou d'accès à la base de données. La couche métier utilise les classes de la couche persistance qui encapsulent ces traitements. Ainsi la couche métier manipule uniquement des objets pour les accès à la base de données.

GL & AGL 19

Notes:

<!-- Slide number: 20 -->

Découpage en couches – Modèle en 3 couches 20


Découpage conforme à une démarche structurée par les cas d’utilisation. On peut s’occuper d’une couche sans savoir à connaitre le détail des autres couches. Minimise les dépendances entre couches. Favorise la standardisation (Framework). Facilite la réutilisation et la substitution (couplage plus faible et mieux contrôlé). La sécurité peut être renforcée.

Complexe. Plus d’exigence. Problèmes au niveau des performances. GL & AGL 20

Notes:

<!-- Slide number: 21 --> # Découpage en couches – Modèle en 5 couches Autre découpage en couches : Modèle en 5 couches Modèle en 3 couches + couches intermédiaires : logique applicative + accès données. Objectifs : Réduire la complexité. Faciliter la réutilisation et la substitution.

IHM

Logique applicative

Métier

Accès Données Middleware Interfaces acteurs systèmes

Gestion des données Infrastructure Acteurs externes GL & AGL 21

Notes:

<!-- Slide number: 22 --> # Découpage en couches – Modèle en 5 couches La couche IHM (Présentation) : Gérer le dialogue Humain-machine : Capter, sous forme d’évènements, les requêtes provenant de l’utilisateur (clavier, souris, voix, etc.) Retranscrire ces évènements sous forme d’envoi de message à destination de la couche applicative. Récupérer la réponse et afficher les résultats.

IHM

Logique applicative

Métier

Accès Données Middleware Interfaces acteurs systèmes

Gestion des données Infrastructure Acteurs externes GL & AGL 22

Notes:

<!-- Slide number: 23 --> # Découpage en couches – Modèle en 5 couches La couche Applicative : Implémenter les services (cas d’utilisation) demandés par l’utilisateur : Utilise les services métier (propres au domaine de l’application, couche inférieure). Utilise les services techniques (authentification, autorisation, etc.). Sollicitée la plupart du temps par l’IHM. Moyennement réutilisable

IHM

Logique applicative

Métier

Accès Données Middleware Interfaces acteurs systèmes

Gestion des données Infrastructure Acteurs externes GL & AGL 23

Notes:

<!-- Slide number: 24 --> # Découpage en couches – Modèle en 5 couches La couche Métier : Implémenter les services atomiques métiers propres au domaine et réutilisables par les applications : Permet de capitaliser le savoir faire de la structure en matière de règles métiers, de règles de gestion et de contrôle de cohérence. Sollicitée par la couche applicative. Potentiellement réutilisable.

IHM

Logique applicative

Métier

Accès Données Middleware Interfaces acteurs systèmes

Gestion des données Infrastructure Acteurs externes GL & AGL 24

Notes:

<!-- Slide number: 25 --> # Découpage en couches – Modèle en 5 couches La couche d’accès aux données : une couche gérant le stockage des données, logiquement nommée couche de données. Il s'agit là des opérations classiques de stockage : la création, la lecture, la modification et la suppression. Ces quatre tâches basiques sont souvent raccourcies à l'anglaise en CRUD.

IHM

Logique applicative

Métier

Accès Données Middleware Interfaces acteurs systèmes

Gestion des données Infrastructure Acteurs externes GL & AGL 25

Notes:

<!-- Slide number: 26 --> # Découpage en couches – Modèle en 5 couches La couche de gestion des données : est la couche qui sert de communicateur avec la base de données. Son avantage est le rôle de sas de sécurité entre l'application et la base de données. Si la structure de données change, seule (en théorie) cette couche est à modifier.

IHM

Logique applicative

Métier

Accès Données Middleware Interfaces acteurs systèmes

Gestion des données Infrastructure Acteurs externes GL & AGL 26

Notes:

<!-- Slide number: 27 --> # Un autre exemple d’architecture en couches :Système d’information orienté web


GL & AGL 27

Notes:

<!-- Slide number: 28 --> # Patron d’architecture : MVC Problème : Un modèle (=un ensemble de données) peut être visualisé à l’aide de différentes vues. Le modèle peut être modifié à partir de n’importe laquelle de ces vues. Quand le modèle est modifié, toutes les vues doivent être rafraichies.

 GL & AGL 28

Notes:

<!-- Slide number: 29 --> # Patron d’architecture : MVC

Solution :

On utilise 3 entités : Modèle: contient les données à afficher Vue: fait l’affichage Contrôleur: coordonne les deux

MVC : le plus connu des patrons d’architecture. Utilise le patron de conception observateur-observé.

 GL & AGL 29

Notes:

<!-- Slide number: 30 --> # Exemple de patron d’architecture : MVC

Le Modèle :

Contient les données à afficher et à modifier.

Définit la logique de manipulation de ces données.

Envoie des événements quand les données sont modifiées.

Ne connait ni la vue ni l’API du contrôleur : Le contrôleur et la vue sont des observateurs, Le modèle est l’observé.

 GL & AGL 30

Notes:

<!-- Slide number: 31 --> # Patron d’architecture : MVC

La Vue :

Est chargée de l’affichage à l’écran.

Envoie des événements correspondants aux actions de l’utilisateur (click, survol, sélection, etc.).

Ne connait ni l’API du contrôleur, ni le modèle.

 GL & AGL 31

Notes:

<!-- Slide number: 32 --> # Patron d’architecture : MVC Le contrôleur :

Assure l’interaction entre données et vue.

Connait la vue et le modèle.

Observe le modèle, modifie la vue en conséquence.

Observe la vue, modifie le modèle en conséquence.

 GL & AGL 32

Notes:

<!-- Slide number: 33 --> # Patron d’architecture : MVC Avantages du MVC : Il peut y avoir plusieurs vues sur le même modèle. Plusieurs contrôleurs peuvent modifier le même modèle. Toutes les vues seront notifiées des modifications.

 GL & AGL 33

Notes:

<!-- Slide number: 34 --> # L’architecture physique Les architecture physique 1-niveau (1-tiers) : Toutes les couches logiques sont situées sur la même machine (Exemple : un mainfarme avec des postes passifs).

Les architecture 2-niveaux (2-tiers) : Les couches logiques sont séparés sur deux sites : Les dispositifs du serveur (BD, service de messagerie, etc.) sur un site Le reste de l’architecture sur les postes client. Permet le partage d’information entre utilisateurs : Accès simultanés, Synchronisation des données. Des variantes existent pour alléger le poste client (Plus d’applicatifs sur le site serveur).

GL & AGL 34

Notes:

<!-- Slide number: 35 --> # L’architecture physique

 Exemple : Répartition de l’architecture logique sur l’architecture physique GL & AGL 35

Notes:

<!-- Slide number: 36 --> # Qualité de la conception architecturale Application de critères de qualité : Faible couplage. Forte cohésion.

Utilisation de patrons de conception : Patrons GoF (Gang of Four). 3 catégories de patrons GoF : De création. De structure. De comportement. GL & AGL 36

Notes:

<!-- Slide number: 37 --> # Critères de qualité de la conception architecturale

Problème : comment réduire l’impact des modifications? Affecter les responsabilités de sorte à éviter tout couplage inutile.

Le couplage est une mesure de degré auquel un élément est lié à un autre, en a connaissance ou en dépend.

S’il y a couplage ou dépendance, l’objet dépendant peut être affecté par les modifications de celui dont il dépend. Exemple : une sous-classe est fortement dépendante de sa super-classe.

Un objet A faisant appel aux méthodes d’un objet B a un couplage aux services de B



 GL & AGL 37

Notes:

<!-- Slide number: 38 --> # Critères de qualité de la conception architecturale Exemple : Facturation Dans un logiciel de gestion de vente, nous avons les classes suivantes : Facture : Contient un ensemble de produits facturés et est associée à un mode de paiement. Paiement : Décrit un mode de paiement (espèces, chèque, carte bancaire, à crédit). Client : Effectue les commandes.

On ajoute une méthode payer() à la classe Client. On étudie le couplage dans les deux cas suivants : La méthode payer() créer une instance de Paiement et l’assigne à l’objet Facture. La méthode payer() délègue l’action à la classe Facture qui crée une instance de Paiement et l’assigne.

GL & AGL 38

Notes:

<!-- Slide number: 39 --> # Critères de qualité de la conception architecturale Le couplage et plus faible dans la deuxième cas car la méthode Payer() de la classe Client n’a pas besoin de savoir qu’il existe une classe Paiement, c’est-à-dire qu’elle ne dépend pas de l’existence ou non de cette classe GL & AGL 39

Notes:

<!-- Slide number: 40 --> # Critères de qualité de la conception architecturale

 Un système a une cohésion si: Les éléments inter reliés sont groupés ensemble. Les éléments indépendants sont dans des groupes distincts.

Exemple : Considérons la modélisation d’une classe Eléphant ayant des propriétés particulières (hauteur et température corporelle). Ajouter des classes de type énumération relatives à l’hauteur et à la température. GL & AGL 40

Notes:

<!-- Slide number: 41 --> # Patrons de conception La normalisation des architectures est grandement facilitée par l’utilisation de Canevas (Framework) et de Patrons (Patterns).

Ils favorisent: La réutilisation La capitalisation d’expérience. GL & AGL 41

Notes:

<!-- Slide number: 42 --> # Patrons de conception Patrons (Patterns) :

Solution générique à un problème (générique). Solution éprouvée. Permet de capitaliser sa propre expérience et celle des autres. L’utilisation de patrons renforce l’abstraction. Le patron fournit une solution à un problème (abstrait) indépendant du domaine. Il existe différents types de patrons : Les patrons d’analyse. Fournissent des solutions réutilisables pour les étapes d’analyse. Les patrons architecturaux. Exp. : MVC (Model View Controller). Les patrons de conception (Design Pattern). Exp. : Singleton, Observer, Factory, etc.

GL & AGL 42

Notes:

<!-- Slide number: 43 --> # Patrons de conception Problème: Quel est le problème récurrent qui se pose?

Nom: Le nom identifiant du patron

Comment on décrit un patron?

Solution générale: Quelle solution générale est proposée

Exemple: Un exemple illustrant l’application du patron GL & AGL 43

Notes:

<!-- Slide number: 44 --> # Patrons de conception – Catégorie des patrons GoF | C | Création | Structurels | Comportementaux | | --- | --- | --- | --- | | Objectifs | Solutions aux problèmes liés à l'instanciation des classes Abstraction du processus d’instanciation Créer des objets sans avoir à connaître la logique de création | Solutions aux problèmes de structuration des classes, d'abstraction, de réutilisation Composition de classes et d’objets pour obtenir des structures plus complexes | Solutions aux problèmes de communication entre objets et d'algorithmique | | Intérêt | Plus de flexibilité aux programmes Décider quel objet créer pour un cas d’utilisation donné | Définir des moyens de composer des objets pour obtenir de nouvelles fonctionnalités | Distribution des responsabilités | | Exemples | Abstract Factory Builder Factory Method Prototype Singleton | Adapter Bridge Composite Decorator Facade Flyweight Proxy | Chain of Responsability Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor | GL & AGL 44

Notes:

<!-- Slide number: 45 --> # Exemple 1 de patron de conception de création Abstract Factory :

Une super-fabrique permettant de créer d’autres fabriques. Création des fabriques à travers une interface. Les objets d’une fabrique sont créés sans avoir à expliciter leurs classes. GL & AGL 45

Notes:

<!-- Slide number: 46 --> # Exemple 1 de patron de conception de création Structure de Abstract Factory :

 GL & AGL 46

Notes:

<!-- Slide number: 47 --> # Exemple 1 de patron de conception de création Exemple avec Abstract Factory :

 GL & AGL 47

Notes:

<!-- Slide number: 48 --> # Exemple 2 de patron de conception de création Prototype :

Spécifie les types d’objets à créer en utilisant un prototype. Créer de nouveaux objets en copiant le prototype (clonage). Fournir de nouveaux objets par la copie d’un exemple plutôt que de produire de nouvelles instances non initialisées d’une classe.

GL & AGL 48

Notes:

<!-- Slide number: 49 --> # Exemple 2 de patron de conception de création Structure du prototype :

 GL & AGL 49

Notes:

<!-- Slide number: 50 --> # Exemple 2 de patron de conception de création Exemple avec Prototype :

 GL & AGL 50

Notes:

<!-- Slide number: 51 --> # Exemple 1 de patron de conception de structure Adapter :

Permet de faire le pont entre deux interfaces incompatibles. Jointure des fonctionnalités de différentes interfaces (indépendantes ou incompatibles) à travers une seule classe. Encapsuler un ensemble de fonctions sous la même implémentation (wrapping/emballage).

 GL & AGL 51

Notes:

<!-- Slide number: 52 --> # Exemple 1 de patron de conception de structure Structure de Adapter :

 GL & AGL 52

Notes:

<!-- Slide number: 53 --> # Exemple 1 de patron de conception de structure Exemple avec Adapter :

 GL & AGL 53

Notes:

<!-- Slide number: 54 --> # Exemple 2 de patron de conception de structure Façade : Cacher la complexité d’un système. Minimiser les communications et les dépendances entre sous-systèmes. Fournir une interface au client à travers laquelle il pourra accéder au système. Fournir au client des méthodes simples à travers une classe unique. Déléguer les appels aux méthodes des classes du système.

 GL & AGL 54

Notes:

<!-- Slide number: 55 --> # Exemple 2 de patron de conception de structure Structure de Façade :


 GL & AGL 55

Notes:

<!-- Slide number: 56 --> # Exemple 2 de patron de conception de structure Exemple avec Façade :

 GL & AGL 56

Notes:

<!-- Slide number: 57 --> # Exemple 1 de patron de conception de comportement Chain of Responsibility :

Créer une chaine d’objets receveurs pour une requête donnée. Chaque receveur contient une référence à un autre receveur. Si un objet ne peut pas traiter une requête, il la fait passer au receveur suivant et ainsi de suite.

GL & AGL 57

Notes:

<!-- Slide number: 58 --> # Exemple 1 de patron de conception de comportement Structure de Chain of Responsibility :

 GL & AGL 58

Notes:

<!-- Slide number: 59 --> # Exemple 1 de patron de conception de comportement Exemple avec Chain of Responsibility :

 GL & AGL 59

Notes:

<!-- Slide number: 60 --> # Exemple 2 de patron de conception de comportement Observer : Définit une dépendance « one-to-many » (un à plusieurs) entre objets de sorte que lorsque l’état d’un objet change, tous ses objets dépendants sont notifiés et mis à jours automatiquement. L'objet observé (Observable) gère une liste d'observateurs (Observer) dotés d'une méthode de mise à jour (update) et notifie les changements aux observateurs en appelant leurs méthodes de mise à jour.

 GL & AGL 60

Notes:

<!-- Slide number: 61 --> # Exemple : Architecture logique en 5 couches/ frameworks et patrons

 GL & AGL 61

Notes: