La conception d’architecture

Le contenu est basé aux transparents du 7 ème édition de «Software Engineering» de Ian Sommerville B.Shishedjiev Génie logiciel 1

Objectifs et activités

• Objectifs – Analyse du système – Communication avec les actionneurs – Réutilisation • Activités – Décomposition – Spécifications des sous-systèmes – Spécifications des échanges (les interfaces) B.Shishedjiev Génie logiciel 2

La gestion des caractéristiques

• Caractéristiques (besoins non-fonctionnels) de lesquelles l’architecture dépend – Performance • Localiser les opérations critiques et minimiser les communications.

– Sécurité • Localiser les éléments critiques pour la sécurité dans peu sous systèmes (dans les couches internes) – Disponibilité • Ajouter des composants redondants et mécanismes tolérant les fautes – Facilité pour maintenance • Utiliser des composants plus fines et réutilisables.

• Conflits – Sécurité contre performance – Facilité contre performance B.Shishedjiev Génie logiciel 3

Structuration et présentation

• Block diagrammes • Diagrammes des classes • Diagramme des composant avec interfaces B.Shishedjiev Génie logiciel 4

Exemple Robot de paquetage

B.Shishedjiev Génie logiciel 5

Décisions de conception architecturale

• Y a-t-il une architecture générique à utiliser?

• Comment va le système être distribué?

• Quel style architectural est approprié?

• Quelle approche va être utilisée de structurer?

• Comment on va décomposer le système en modules • Quelle stratégie de gestion on va utiliser?

• Comment on va évaluer le projet architectural?

• Comment on va documenter le projet?

B.Shishedjiev Génie logiciel 6

Les modèles architecturals

• Modèle statique de structure – les composants principaux • Modèle dynamique des processus • Modèle de l’interfaces des relations sous système.

• Modèle des relations – DFD et sous systèmes.

• Modèle de distribution entre les nœuds.

B.Shishedjiev Génie logiciel 7

Organisation du système

• 3 Styles d’organisation principaux – Donnés partagées (style d’entrepôt); – Services partagées (style serveur); – Machine abstraite (style en couches).

B.Shishedjiev Génie logiciel 8

Le modèle entrepôt (de données)

• CASE système B.Shishedjiev Génie logiciel 9

Le modèle entrepôt (de données)

• Deux moyens d’échange des données entre les sous systèmes – Un entrepôt – Chaque sous-système a son propre dépositaire des données • Avantages de style entrepôt – Efficace pour l’échange des grands quantités de données; – Les sous-systèmes n’ont pas le besoin de gérer les données.

– Le modèle des données est unique.

• Désavantages – Tout sous-système doit utiliser le même modèle; – L’évolution des données est difficile; – Difficile pour distribuer.

B.Shishedjiev Génie logiciel 10

Client 1

Modèle client serveur

Client2 Client 3 Client4 Serveur catalogue Catalogue Serveur video Video extraits Internet haut d ébit Serveur photo Des photos digitales Serveur hyper texte Pages hypertexte B.Shishedjiev Génie logiciel 11

Modèle client serveur

• Avantages – Distribution des données est simple; – On utilise effectivenent les réseaux; – C’est facile d’ajouter des nouveaux serveurs ou de moderniser les existants.

• Désavantages – Il n’y a pas un modèle unique des données et l’échange peut être ineffective; – Gestion redondante de chaque serveur; – Il n’y a pas un registre central des services et données. Ça peut poser des problèmes.

B.Shishedjiev Génie logiciel 12

Machine abstraite

• Particularités – Modélise l’interface entre les sous-systèmes – Organisé en couches – Efficace quand on développe en incréments • Désavantages – Structuration plus difficile et un peu artificielle B.Shishedjiev Génie logiciel 13

Machine abstraite

• Système de gestion des versions Couche de gestion de la configuration Couche de gestion des objets Couche de base de données Couche de système d’exploitation B.Shishedjiev Génie logiciel 14

Décomposer en modules

• Différence entre sous système et module?

– Le sous système et un composant dont l’opération ne dépend pas des autres sous systèmes – Le module assures des services aux autres composants mais il n’est pas considéré comme un système séparé. • Modèles de décomposition – Modèle objet – Modèle pipeline B.Shishedjiev Génie logiciel 15

Modèle objet

• Particularités – Il présente le système comme un ensemble d’objets qui sont faiblement connectés – Ils ont des interfaces bien définis.

• Avantages et désavantages – Les objets sont faiblement connectés et leur modification ne concerne pas les autres objets – Les objets sont souvent des entités réelles – On utilise des langages OO pour les implémenter – Quand les objets sont complexes la modélisation est difficile B.Shishedjiev Génie logiciel 16

Modèle objet

• Système de facturation B.Shishedjiev Génie logiciel 17

Pipeline orienté fonctionnellement

• Particularités – Il présente le système une pipeline de traitement des données – Très commun pour un traitement consécutif • Avantages et désavantages – Approprié pour les processus en lots (batch) – Facile pour réutilisation tes transformation.

– Organisation intuitive appropriée pour communiquer avec les actionneurs.

– On peut ajouter facilement des nouvelles transformations.

– Implémentation simple dans systèmes séquentielles et parallèles – Pas bon pour les systèmes interactifs B.Shishedjiev Génie logiciel 18

Pipeline orienté fonctionnellement

• Système de facturation B.Shishedjiev Génie logiciel 19

Styles de gestion

• Modèles de flux de contrôle • Types – Contrôle centralisé • Un sous-système gérant gère les autres directement ou indirectement – Systèmes gérés par événements • Le système réagisse aux événements externes ou internes B.Shishedjiev Génie logiciel 20

Contrôle centralisé

• Modèles – Modèle appel - retour (call-return) – Modèle de gérant centralisé (manager) B.Shishedjiev Génie logiciel 21

Modèle appel - retour (call-return)

B.Shishedjiev Génie logiciel 22

Modèle de gérant centralisé

• Système de temps réel B.Shishedjiev Génie logiciel 23

Systèmes gérés par événements

• Types – De diffusion (broadcasting) – l’événement est émis vers tous les sous systèmes et une d’eux le traite – Gérés par interruptions – les interruptions sont découverts par des pilotes qui les passent au quelque composant.

B.Shishedjiev Génie logiciel 24

Le modèle de diffusion

• Ce modèle est effective quand il y a beaucoup événement différents et chaque composants peut traiter certains d’eux.

• Le modèle de traitement n’est pas dans le pilote mais dans le composant traitant • Diffusion sélective B.Shishedjiev Génie logiciel 25

La gestion d’interruptions

• Chaque interruption a son pilote qui est appelé immédiatement. Après le traitement le contrôle est retourné dans le point d’interruption.

• Utilisé dans les systèmes de temps réel.

B.Shishedjiev Génie logiciel 26

La gestion d’interruptions

Interrupts Interrupt vector Handler 1 Handler 2 Handler 3 Process1 Process2 Process3 Handler 4 Process4 B.Shishedjiev Génie logiciel 27

Architectures de référence

• Architectures spécifiques de certain domaine • Types – Modèles génériques – généralisés de certains systèmes réels – Modèles de référence • abstrait et plus théoriques.

• Dérivés du domaine • Peuvent servir comme standard pour validation et évaluation des architectures B.Shishedjiev Génie logiciel 28

Architectures de référence

• Modèle OSI 7 6 5 4 3 2 1 Ap pli cat io n Present a t io n Session Transp or t Net wo rk Dat a li nk Phy sical Net wo rk Dat a li nk Phy sical Co m m uni ca t io ns medium Ap pli cat io n Present a t io n Session Transp or t Net wo rk Dat a li nk Phy sical B.Shishedjiev Génie logiciel 29

Tool slots

ECMA architecture pour CASE

Data repository services Data integration services Task management services User inter face services Message services B.Shishedjiev Génie logiciel 30

Modèle de référence ECMA

• Data repository services – Gérer et stocker les données.

• Data integration services – Gérer des groupes d’entités et les relations entre eux.

• Services de gestion des tâches – Définition et énaction des modèles de processus.

• Messaging services – Communication Outil-outil et outil-environnement • User interface services – Développement de l'interface utilisateur.

B.Shishedjiev Génie logiciel 31