Le contenu est basé aux transparents du 7ème édition
de «Software Engineering» de Ian Sommerville
B.Shishedjiev - Génie logiciel 1
La conception d’architecture
B.Shishedjiev - Génie logiciel 2
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 3
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 4
Structuration et présentation
• Block diagrammes• Diagrammes des classes• Diagramme des composant avec interfaces
B.Shishedjiev - Génie logiciel 5
Exemple Robot de paquetage
B.Shishedjiev - Génie logiciel 6
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 7
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 8
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 9
Le modèle entrepôt (de données)• CASE système
B.Shishedjiev - Génie logiciel 10
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 11
Modèle client serveur
Client2
Internet haut débit
Client 1Client4Client 3
Serveurcatalogue
Catalogue
Serveur video
Video extraits
Serveur photo
Des photosdigitales
Serveur hypertexte
Pageshypertexte
B.Shishedjiev - Génie logiciel 12
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 13
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 14
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 15
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 16
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 17
Modèle objet• Système de facturation
B.Shishedjiev - Génie logiciel 18
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 19
Pipeline orienté fonctionnellement• Système de facturation
B.Shishedjiev - Génie logiciel 20
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 21
Contrôle centralisé
• Modèles– Modèle appel - retour (call-return)– Modèle de gérant centralisé (manager)
B.Shishedjiev - Génie logiciel 22
Modèle appel - retour (call-return)
B.Shishedjiev - Génie logiciel 23
Modèle de gérant centralisé• Système de temps réel
B.Shishedjiev - Génie logiciel 24
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 25
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 26
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 27
La gestion d’interruptions
Handler
1
Handler
2
Handler
3
Handler
4
Process1 Process2 Process3 Process4
Interrupts
Interrupt vector
B.Shishedjiev - Génie logiciel 28
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 29
Architectures de référence• Modèle OSI
Presentation
Session
Transport
Network
Data link
Physical
7
6
5
4
3
2
1
Communications medium
Network
Data link
Physical
Application
Presentation
Session
Transport
Network
Data link
Physical
Application
ECMA architecture pour CASE
B.Shishedjiev - Génie logiciel 30
Toolslots
Messageservices
Task management services
User interface services
Data repository services
Data integration services
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
Top Related