Conception architecturale. GLO-3001 Architecture logicielle Luc Lamontagne Hiver 2010

Transcription

1 Conception architecturale GLO-3001 Architecture logicielle Luc Lamontagne Hiver 2010

2 Plan Introduction Survol général Facteurs architecturaux (attributs de qualité) Approche par scénarios Tactiques de conception Approche Attribute Driven Design (ADD) Description détaillée pour quelques facteurs Autres facteurs ou attributs de qualité Détail de l approche de conception ADD

3 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

4 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

5 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

6 Qualité Les propriétés non-fonctionnelles du système 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

7 Qualité vs. fonctionnalité Les systèmes sont souvent modifiés Difficile à maintenir, lent, peu fiables. Ce sont tous des critères de qualité. Qualité => orthogonale aux fonctionnalités Par ex. fonctionnalités = performance? Combien de composantes? Niveau de qualité indépendant des fonctionnalités. 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

8 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 Réutiliser des données saisies précédemment.

9 Attributs de qualité Critères étudiés par le SEI La disponibilité (availability) La modifiabilité (modifiability) La sécurité (security) L utilisabilité (usability) La performance La testabilité (testability)

10 Attributs de qualité Disponibilité : Comment gérer la redondance des composantes. Modifiabilité : Performance : Sécurité : Testabilité : Utilisabilité : Comment modifier le système tout en limitant les coûts et le temps. La gestion du temps de réponse à des événements La capacité du système à résister à un usage nonautorisé tout en fournissant un service à ses usagers La facilité d un logiciel à démontrer ses erreurs par des techniques de tests La facilité d un usager à accomplir une tâche et le type de support que le système lui fourni

11 Attributs de qualité Attributs étudiés dans la littérature du génie logiciel 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

12 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 Le système ou une composante Le résultat de l activité menée par le système L entité qui génère le stimulus (ex. un usager, un autre système ) La condition du système (ex. normal, surcharge) Une mesure de la réponse

13 Scénario de disponibilité Scénario général Présente l étendue des valeurs possibles Sert d aide mémoire (checklist) Exemple de scénario spécifique Dérivé du scénario général Décrit des besoins particuliers Suffisamment détaillé pour l architecte La réponse est suffisamment signifiante pour être évaluée

14 Tactiques Scénarios de qualité Définition des besoins en qualité d un logiciel 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

15 Tactiques Les tactiques influencent le contrôle d une réponse pour un attribut de qualité particulier Ex : Disponibilité

16 Lien avec les patrons de conception 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.

17 Approche de conception ADD Un exemple de cycle de développement Lien étroit (itération) entre les besoins et la conception architecturale Utilisation des tactiques pour mener cette phase

18 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

19 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.

20 Facteur architectural Disponiblité (availability) GLO-3001 Architecture logicielle Luc Lamontagne Hiver 2010

21 Disponibilité (availability) Reliée aux défaillances de systèmes et aux conséquences correspondantes 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

22 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»

23 Disponibilité: scénario Points importants Comment détecter les défaillances La fréquence des défaillances Ce qui se produit lorsqu'il y a une défaillance Comment les prévenir Quel notification fournir suite à une défaillance 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

24 Disponibilité: scénario Définition tempsmoyen jusqu'à une défaillanc e tempsmoyen jusqu'à une défaillanc e tempsmoyen de réparation 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.

25 Disponibilité: scénario

26 Disponibilité: scénario Portion de scénario Source Stimulus Artefact Environnement Valeurs possibles Indication interne ou externe (au système) de défaillance 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) Réponse 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 Mesure de réponse 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) Temps de réparation

27 Tactiques de disponibilité Tactiques: Vise à empêcher les fautes de devenir des défaillances; ou Limiter les effets de ces fautes et rendre les réparations possibles

28 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 la surveillance de l état des composantes une récupération après une défaillance

29 Disponibilité Tactiques: Détection de fautes 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 Message (ping) Réponse Composante surveillée

30 Disponibilité Tactiques: Détection de fautes Battement de coeur (heartbeat) Émission de messages périodiquement Plus de message faute action Messages Composante Surveillante? Composante surveillée

31 Disponibilité Tactiques: Détection de fautes 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 Service offert Exception Composante surveillée

32 Disponibilité Tactiques: 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 Client Décision Serveur 1 Requête Serveur 2 Réponses Serveur 3 Traitement de la requête

33 Disponibilité Tactiques: Tolérance aux fautes 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. Client Décision Serveur 1 Requête Serveur 2 Réponses Serveur 3 Traitement de la requête

34 Disponibilité Tactiques: 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 Client Requête Serveur 1 - primaire Serveur 2 Traitement de la requête Mise à jour Serveur 3 Décision Réponse Panne primaire

35 Disponibilité Tactiques: Tolérance aux fautes 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. Client Serveur 1 - primaire Requête Décision Réponse Panne Serveur 2 Traitement de la requête Checkpoints & changements Réinitialiser

36 Disponibilité Tactiques: Tolérance aux fautes Tactiques pour réintroduire une composante défaillante Shadow operation On roule en parallèle avant la remise en service Checkpoint rollback Enregistrement périodique de l état

37 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.