Off the record

Aller au contenu | Aller au menu | Aller à la recherche

vendredi 9 février 2007

Spécifications...et MDA

Finalement, la frontière entre les specs fonctionnelles et techniques est souvent trop peu marquée, de même que la frontière entre les spécifications techniques et l'architecture... Voila quelques exemples tout bêtes qui m'en ont fait comprendre plus que les absconces définitions habituelles :

Les spécifications fonctionnelles (le plus facile) décrivent des comportements et aspects du systême:

  • authentification
  • navigation
  • contenu des vues

Les spécifications techniques décrivent des qualités du systême, par exemple :

  • scalabilité
  • performance
  • résistance aux pannes (exemple tolérance 99.9%)

On en vient à MDA : model driven architecture, qui est une nouvelle approche de la conception logicielle.
MDA tend à découpler au maximum la conception et l'architecture, et également à produire directement le code à partir du modèle.
La conception traite les spécifications fonctionnelles et l'architecture les specs techniques.
Ainsi, si l'on conçoit un modèle conceptuel implémentant les spécifications fonctionnelles, et que l'on a un traducteur modèle->architectureX qui va produire le code selon l'architecture X, on obtient les effets suivants :

  • chaque modification des spécifications implique une modification du modèle, et une nouvelle génération (automatique !) du systême.
  • Si finalement l'architecture X ne répond pas ou répond mal aux specs techniques, on change le traducteur et on prend modèle->architectureY, ce qui génère automatiquement une solution technique totalement diffèrente, mais implémentant exactement de la même manière les specs fonctionnelles !


C'est presque magique. Plus qu'à acheter les traducteurs...Voila le problème...Ils ne sont pas en rayon chez Monoprix ou Migros et en écrire un soi même, c'est comme pour les langues. Si on sait juste dire bonjour en chinois on fera un traducteur qui ne sait faire qu'un "hello world".
MDA reste une technologie extrêmement prometteuse, en particulier pour la création de maquettes. Lorsqu'on a construit un traducteur incluant un pan raisonnable d'une technologie, il est possible de construire une application avec des fonctionnalités basiques en quelques minutes.
Avec deux traducteurs, exemple Java EE et .Net, on pourra aller jusqu'à effectuer des comparatifs d'architecture.

Article sur wikipedia

vendredi 2 février 2007

Performance testing, load testing or stress testing?

Il est important de comprendre les différences entre ces trois types de testing. Performance, stress et charge. Selon le vocabulaire établi :

  • les tests de performance sont menés pour valider le fait que le systême va donner un temps de réponse correct à son ou ses utilisateurs dans les conditions d'utilisation normales définies. Par exemple, 400 utilisateurs effectuant des requêtes concurrentes, temps de réponse maximum 4s pour une requête donnée. Ces tests vont permettre de repérer les goulots d'étranglement à tous les niveaux et ainsi permettre de gagner en...performance.
  • le stress testing permet de valider que le systême va savoir réagir correctement en cas de disfonctionnement d'un des modules qui le constitue. L'état est-il sauvé avant clôture? L'état du systême est-il correctement restauré au redémarrage. Les cas de stress habituels sont par exemple :
    • chute du réseau / d'un ou plusieurs ports réseau
    • chute du serveur de base de données
    • forte charge en terme d'utilisateurs
  • Enfin, les tests de charge cherchent à détecter des bugs ou erreurs de conception qui n'apparaissent qu'en cas de charge réelle du systême. On recherche classiquement les fuites de mémoires...Ce type de test s'appelle aussi volume testing ou endurance testing.

Toute une batterie d'outils existe pour mener ces tests, simuler plusieurs milliers d'utilisateurs etc, je citerais le projet Apache Jmeter, parce que c'est écrit en Java et parce que c'est open source !

Mes sources d'inspiration sur ce sujet :