Introduction

Les systèmes informatiques connaissent une croissance exponentielle aussi bien en termes de taille que de complexité car les utilisateurs attendent toujours plus de leurs applications. Dans un monde connecté, les applications doivent interagir avec d’autres applications, et s’exécuter dans différents environnements comme dans le Cloud et sur des périphériques mobiles. La plupart des conceptions monolithiques courantes du passé a été remplacée par des conceptions architecturées, bien concises et réfléchies.

Selon le livre “Software architecture in practice (third edition)”, l’architecture logicielle est définie comme suit :

 L’architecture logicielle d’un système est l’ensemble des structures nécessaires pour raisonner sur le système, ce qui comprend les éléments logiciels, les relations qui existent entre ces éléments, et les propriétés des éléments et des relations

L’architecture est un pont entre les besoins exprimés par les clients et le système que l’on doit faire réaliser. Un architecte doit savoir ce qui fait qu’une architecture satisfait les exigences du client. Il doit aussi avoir une vision globale du système à concevoir ou à maintenir car n’avoir que des compétences techniques n’est pas suffisant.

Plusieurs raisons font qu’une architecture est satisfaisante, entre autres on cite  :

• Doit avoir une liste d’attributs de qualité bien définie et triée par priorité
• Doit fournir des modules bien définis
• Ne doit jamais dépendre d’une version particulière d’un produit ou d’un outil

Pour plus de détails, je vous propose la lecture de “Designing software architecture”.

Dans cet article nous allons comprendre comment atteindre certains attributs de qualité.

Cependant, nous ne pouvons pas comprendre comment améliorer la performance sans comprendre ce qu’est la performance.

Architecture et exigences

Quel que soit le type d’architecture utilisée, les exigences sont de trois types :

• Les exigences fonctionnelles

  Ces exigences spécifient :

  • Ce que le système doit faire
  • Comment doit-il réagir à certains événements lors de l’exécution ?

• Les exigences relatives aux Attributs de Qualité

  Elles précisent comment le système doit fournir les fonctionnalités. Selon le livre “Software architecture in practice”, les attributs de qualité sont définis comme étant des propriétés mesurables et vérifiables d’un système. Ils font partie des exigences non fonctionnelles.

• Les contraintes
  C’est ce qui doit être pris en compte quoi qu’il arrive. Par exemple : l’accès au réseau, l’environnement ou la puissance de calcul du matériel. Des décisions qui ont déjà été prises et sur lesquelles on ne peut plus faire marche arrière peuvent également devenir des contraintes.

En sachant q’une architecture est une suite de décisions qui découle de ce que l’on a compris du problème, on prend ces décisions selon les caractéristiques que doit avoir un produit.

Cependant, pour prendre une décision, on doit définir le besoin et la qualité attendue du produit, des besoins et des qualités définis par le client, qui souvent ne sait pas comment les exprimer.

Il existe un moyen permettant de décrire les objectifs que l’on veut exprimer de façon claire et compréhensible :  “SMART” (https://fr.wikipedia.org/wiki/Objectifs_et_indicateurs_SMART🙂

• Spécifique  : un objectif spécifique doit être en lien direct avec le travail de la personne chargée de le réaliser ; il doit être personnalisé. Par ailleurs, un objectif peut être également qualifié de simple car il doit être simple à comprendre, clair, précis pour plus d’efficacité, car la complexité ralentit la réalisation. De plus, il faut que l’objectif ait une légitimité aux yeux de tous.

• Mesurable : un objectif mesurable doit être quantifié ou qualifié. Pour réaliser un objectif, la définition d’un seuil est nécessaire afin de savoir quel est le niveau à atteindre, la valeur de la mesure à rencontrer. Il n’est pas possible de choisir un objectif que l’on ne peut quantifier ou qualifier par souci d’évaluation des moyens nécessaires pour l’atteindre.

• Atteignable : un objectif acceptable est un objectif suffisamment grand, ambitieux pour qu’il représente un défi et qu’il soit motivant. Par ailleurs cet objectif doit être atteignable et donc raisonnable, favorisant ainsi l’adhésion des participants à ce dernier. Ainsi, l’objectif sera plus facilement accepté par chacun des acteurs.

• Réaliste : un objectif réaliste est un objectif pour lequel le seuil du réalisme est défini. C’est-à-dire un niveau pour lequel le défi motivera le plus grand nombre de participants et évitera au mieux l’abandon de certains participants au fur et à mesure de la progression de l’objectif.

• Temps défini: un objectif temporellement défini est délimité dans le temps, avec une date butoir et, éventuellement, des dates intermédiaires. L’objectif doit être clairement défini dans le temps par des termes précis comme « d’ici 3 mois » et non pas par des termes flous comme « le plus rapidement possible ».

Les objectifs SMART aideront l’équipe à partager la même vision de ce qui doit être rendu, comment et quand et ainsi éviter que le projet soit un échec.

Attributs de qualité

Les attributs de qualité (AQ) intéressent la communauté du logiciel depuis les années 70. Plusieurs problématiques sont apparues depuis selon le livre “Software architecture in practice” :

• Définitions non testables par manque d’information sur ce qu’est un système modifiable/robuste
• Appartenance de chaque qualité à un attribut bien défini, par exemple : un déni de service tient-il de la disponibilité, de la performance, de la sécurité ou de l’utilisabilité ?
• En plus des autres problèmes rencontrés, chaque communauté avait développé son propre vocabulaire : événements, attaques…

La solution proposée par la communauté est d’utiliser des scénarios d’attributs de qualité et aussi de discuter de chaque attribut afin de montrer les concepts sous-jacents.

Catégories d’attributs de qualité

On peut diviser les attributs de qualité en deux parties :

• Ceux qui décrivent certaines propriétés du système lors de son exécution :
  • la disponibilité
  • la performance
  • l’utilisabilité
• Ceux qui décrivent certaines propriétés du développement du système :
  • la capacité d’être modifiable
  • la testabilité

Comment définir et atteindre chaque attribut de qualité sera abordé dans la deuxième partie de cet article.

Il faut savoir que dans les systèmes les plus complexes, les attributs de qualité ne sont jamais atteints de façon isolée.

Spécifier les exigences relatives aux attributs de qualité (EAQ)

les attributs de qualité sont spécifiés par l’écriture d’un scénario. Pour cela, il existe un format commun afin que l’exigence de l’attribut de qualité soit non ambiguë et testable; un scénario doit répondre au format suivant :

• La source du stimulus : c’est une entité (un humain, un système…) qui génère un stimulus
• Le stimulus : l’événement déclencheur qui peut être interne ou externe
• L’environnement : l’événement déclencheur survient dans certaines conditions. Le système peut être en surcharge ou en cours d’exécution lorsque le stimulus se produit, autrement dit c’est l’ensemble des circonstances dans lesquelles le scénario survient.
• Artefact : l’environnement auquel le scénario s’applique
• Réponse : ce qui se produit systématiquement après un stimulus
• Mesure de la réponse  : la réponse doit être mesurable et testable

Le prochain article sera dédié à l’écriture de scénarios pour chaque attribut de qualité, en se basant sur ce format pour avoir toutes les informations nécessaires afin de prendre des décisions pour avoir une architecture satisfaisante.

Conclusion

Définir l’architecture est une étape essentielle du développement d’un système, l’étape durant laquelle sera décidée sa décomposition en composants et la manière dont ces composants communiqueront. Une mauvaise décomposition aura des répercussions sur le produit, qu’il sera très difficile et coûteux de corriger par la suite.

Les attributs de qualité sont les facteurs globaux qui affectent le comportement d’un système, la conception du système et l’expérience utilisateur. Ils représentent une partie importante de la prise de décision de l’architecte, il est important de mettre en place pour chaque attribut de qualité un scénario sous forme de stimulus – artefact – réponse.

il existe plusieurs livres qui abordent ce point. Pour plus de détails à ce sujet :

• Designing Software Architectures a practical approach – Humberto Cervantes & Rick Kazman – Addison Wesley
• Patterns, principles and practices of Domain Driven Design – Scott Millett with Nick Tune Wrox
• Software Architecture in practice (3rd Edition) (SEI Series in Software Engineering) – Len Bass, Paul Clements & Rick Kazman

© SOAT
Toute reproduction interdite sans autorisation de l’auteur.