Conception architecturale• Description détaillée pour quelques facteurs • Autres facteurs ou attributs de qualité • Détail de l’approche de conception ADD
Introduction
• Pour cette partie du cours, nous étudions l’approche proposée par le Software Engineering Institute (SEI) – Voir livre de Bass, Clements et Kazman
• Approche basée sur le degré de qualité qu’un logiciel doit atteindre – Attribute Driven Design (ADD)
• Constitue une extension aux approches actuelles en conception orientée-objet
Qualité vs. fonctionnalité
• Un système est conçu afin de remplir certaines tâches biens définies
• On recherche également certaines caractéristiques qui permettront une conception et une maintenance plus facile, plus rapide et moins coûteuse du système
Fonctionnalités
• La capacité du système à effectuer les tâches pour lesquelles il a été conçu
• Aucune organisation particulière des composantes afin de réaliser une tâche donnée – Un système monolithique et/ou désorganisé peut
très bien remplir la tâche pour laquelle il a été conçu
– Les fonctionnalités sont indépendantes de la structure du système
Qualité
– c'est-à-dire qu'elles n'influencent pas les fonctionnalités offertes par le système
– Elles sont plutôt des propriétés qui influencent
• le temps et le coût de développement du système,
• son déploiement,
• sa maintenance,
• sa robustesse,
• sa sécurité,
• sa performance…
– Difficile à maintenir, lent, peu fiables.
– Ce sont tous des critères de qualité.
• Qualité => orthogonale aux fonctionnalités
– Par ex. fonctionnalités = performance ?
– Pas toujours possible d’atteindre n’importe quel niveau
• Ex : manipulation d’images ou de vidéo
– L’architecte doit étudier les attributs de qualité
• Savoir comment faire des choix qui influencent la qualité d’un logiciel
Niveau de qualité
• Niveau de qualité d’un logiciel – Pas uniquement atteint par une bonne conception architecturale
– Dépend du niveau global (architecture) et des détails (implémentation)
• Exemple
– L’utilisabilité de l’interface usager dépend de ces deux niveaux. • Aspects non architecturaux
– Construction de l’interface clair et facile à utiliser.
– Utiliser un bouton radio ou un checkbox?
– Quel disposition adoptée pour placer les éléments graphiques?
• Décisions architecturales – Canceller des opérations
– Faire des undo
Attributs de qualité
– La disponibilité (availability)
– La modifiabilité (modifiability)
– La sécurité (security)
– L’utilisabilité (usability)
Modifiabilité :
Performance :
Sécurité :
Testabilité :
Utilisabilité :
La capacité du système à résister à un usage non-
autorisé tout en fournissant un service à ses usagers
La gestion du temps de réponse à des événements
Comment modifier le système tout en limitant les
coûts et le temps.
La facilité d’un usager à accomplir une tâche et le
type de support que le système lui fourni
La facilité d’un logiciel à démontrer ses erreurs par
des techniques de tests
• 3 problèmes limitant leur utilisation en conception
– Les définitions ne sont pas opérationnelles
• ex: « le logiciel doit être modifiable » ça ne veut rien dire!
– Quel attribut appartient à quel critère ? • Ex: une panne disponibilité, sécurité, utilisabilité ?
– Chaque communauté a développé son vocabulaire. • Input = un événement, une défaillance, une attaque…
Scénario d’attribut de qualité
• Une solution proposée pour éviter ces problèmes
– Extension des cas d’utilisation
– Cadre de référence
Une condition qui se produit
dans le système
la réponse
menée par le système
Exemple de scénario spécifique
Présente l’étendue des
– N’indique pas comment les atteindre
• Tactiques
– Une décision de conception qui satisfait un attribut de qualité
– Obtenues des expériences des architectes logicielles
– Présentées comme une hiérarchie pour chaque attribut
– Exemple: introduire de la redondance pour augmenter la disponibilité • Redondance de traitement ou de données
• Besoin de synchronisation
Tactiques
• Les tactiques influencent le contrôle d’une réponse pour un attribut de qualité particulier
• Ex : Disponibilité
• Tactiques satisfaire certains scénarios.
• On utilise les patrons de conception pour concrétiser certaines tactiques.
• La plupart des patrons influence plus d’un attribut de qualité – Exemples :
• Un MVC a un impact sur la modifiabilité et l’utilisabilité d’un interface usager
• Une façade, un médiateur ou un proxy ont un impact sur la modifiabilité et la performance d’un système.
Approche de conception ADD
Utilisation des tactiques
et la conception architecturale
Approche de conception ADD
• Formuler les scénarios de qualité et les besoins fonctionnels (use cases).
• Choisir un module à décomposer
• Raffiner le module en suivant ces étapes : – Choisir les facteurs architecturaux (scénarios et use cases).
– Choisir une tactique architecturale (et/ou un patron) qui satisfait les facteurs architecturaux.
• Identifier les sous-modules requis pour implanter la tactique.
– Instancier les modules et allouer les fonctionnalités provenant des uses cases. Décrire à l’aide de vue (documentation).
– Définir les interfaces des sous-modules.
– Vérifier et raffiner les use cases et les scénarios de qualité et s’en servir comme contraintes pour les sous-modules.
• Répéter les étapes précédentes pour chaque module qui doit encore être décomposé.
N.B: A revoir plus en détail après avoir étudié les différentes tactiques
Conception architecturale et RUP
• Commence tôt dès la phase d’inception – Mais difficile de satisfaire les exigences à ce stade-ci.
• Élaboration – On devrait implémenter les éléments architecturaux à plus haut risque. – L’analyse architecturale est surtout menée durant cette phase.
• Transition – On peut revoir les décisions et les facteurs architecturaux pour vérifier qu’il décrit
correctement le système final déployé.
• Cycle d’évolution ultérieures – Avant de concevoir de nouvelles version du logiciel, réviser.
Facteur architectural
Disponiblité (availability)
• Défaillance
– Lorsque le système ne fournit plus un service qui correspond à ses spécifications
– Une défaillance est observable par les usagers du système
• Soit des humains ou d’autres systèmes
Disponibilité: Exemple de scénario
• « Un message externe d’erreur est reçu par un processus durant des opérations en mode normal. Le processus informe l’opérateur de la réception du message et continue à opérer sans temps d’arrêt »
Disponibilité: scénario
• Points importants
– Comment les prévenir
• Faute vs. dédaillance
– Faute (Fault): ne peut être détecté par l’usager du système
• Exemple: le choix d’un mauvais algorithme
• Peut éventuellement causer une défaillance
– Défaillance (Failure): observable par l’usager du système
Disponibilité: scénario
• Définition
– Par exemple, une disponibilité de 99,9% implique une probabilité de 0,1% que le système ne sera pas opérationnel lorsque nécessaire
– Les périodes de service ne sont pas incluses dans cette définition.
réparation demoyen temps edéfaillanc une àjusqu'moyen temps
edéfaillanc une àjusqu'moyen temps
Source
Stimulus
Artefact
Environnement
Réponse
Faute de type: omission, crash, timing, réponse
Processeur, canal de communication, dépôt persistant, processus du système
Opération normale ou en mode dégradé (i.e., moins de fonctionnalités, solution de rechange)
Le système devrait détecté les événements et prendre l’une des actions suivantes: • Enregistrer la défaillance • Aviser les intervenants appropriées (usager ou autres systèmes) • Désactiver la source des événements qui cause la défaillance • Devenir non disponible pour un temps prédéterminé (dépend de la criticalité du système) • Continuer à opérer en mode normal, passer en mode dégradé ou éteindre le système
• Intervalle de temps durant lequel le système doit être disponible – Pourcentage de disponibilité • Intervalle de temps durant lequel le système peut être en mode dégradé (ou non
disponible)
– Vise à empêcher les fautes de devenir des défaillances; ou
– Limiter les effets de ces fautes et rendre les réparations possibles
Disponibilité: tactiques • Plusieurs déjà préconisées dans des environnements connus
– les systèmes d’exploitation, les serveurs d’application, la gestion de BD.
• Toutes les approches misent sur:
– une redondance de composantes
– une récupération après une défaillance
Disponibilité –Tactiques:
• Ping\echo • Une composante en surveille une autre
• Échange de message et de réponse pour établir la présence de la composante surveillée
Composante
Surveillante
Composante
surveillée
Composante
Surveillante
Composante
surveillée
Messages
• Exceptions
– Si la composante est elle-même responsable de la détection des fautes
– On génère une exception lorsqu’une faute survient.
Composante
Surveillante
Composante
surveillée
Tolérance aux fautes
• Vote – Plusieurs processus sur des processeurs redondants – On fourni à chacun un input équivalent. – Résultats divergent processus mis hors de fonction. – Algorithmes possibles majorité, composante préférée…
DécisionClient
Serveur 1
Serveur 2
Serveur 3
• Redondance active – Des composantes redondantes répondent aux événements en
parallèle. – Le système utilise une seule de ces réponses. – Composante défaillante resynchroniser avec les autres.
Décision Client
Serveur 1
Serveur 2
Serveur 3
Tolérance aux fautes
• Redondance passive – Une seule composante répond aux événements (composante primaire) – Elle informe les autres des mises à jour qu’elles doivent faire – Faute à la composante primaire composante de remplacement – Le temps d’arrêt est de quelques secondes
Décision Client
• Rechange (Spare) – Une composante de rechange peut remplacer plusieurs autres composantes
différentes. – On doit faire des checkpoints de l’état du système et sauvegarder tous les
changements dans une BD. – Le temps d’arrêt peut être de quelques minutes.
Décision Client
• On roule en parallèle avant la remise en service
– Checkpoint rollback • Enregistrement périodique de l’état
Disponibilité –Tactiques:
Prévention de fautes
– Mise hors d’usage • On retire une composante pour mener des activités pour prévenir les
défaillances. – Par exemple, on redémarre une composante pour prévenir les fuites de mémoires.
• Si le retrait de la composante est automatique, alors il faut le prévoir dans l’architecture du logiciel.
• Si c’est manuel, il faut prévoir une composante pour supporter cette activité.
– Transactions • On regroupe plusieurs étapes de traitement ensemble
• On doit compléter toutes les étapes pour une exécution fructueuse
• On veut éviter de corrompre les données si toutes les étapes ne peuvent pas être complétées.
– Moniteur de processus • Suite à la détection d’une faute, le moniteur retire le processus et crée une
nouvelle instance.