Cet article fait partie d’une série d’article sur l’architecture logicielle. Il est la suite du précédent article : introduction aux concepts de l’architecture logicielle.

Nous allons parler dans cet article de la phase d’architecture en amont du développement. Comme indiqué dans l’article précédent, cette phase doit être justement dosée pour ne pas tomber dans les affres de la sur-spécification : elle doit définir la vision technique du projet, mais pas plus.

Nous commencerons par voir les objectifs de l’architecture logicielle avant d’expliciter les outils concrets pouvant être utilisés lors des spécifications, dans cet objectif d’en faire “juste assez”.

Les objectifs de l’architecture logicielle avant projet

Dans cette première partie je vous propose de découvrir la philosophie de la phase d’architecture au travers de son triple objectif : donner une vision technique, préparer la structure du logiciel et identifier les principaux risques.

Dans cette approche l’architecture logicielle se limite à définir l’objectif (la destination) en suivant un ensemble de règles de bonnes pratiques, mais sans détailler le chemin pour y parvenir. Dans cette optique l’architecture doit être porteuse d’une vision claire afin de correctement guider l’équipe de développement dans son travail.

En effet, comme indiqué dans l’article introductif, l’architecture amont ne doit pas entrer dans les détails de la conception, mais laisser les développeurs s’en emparer pour faire “émerger” l’architecture au fur et à mesure de l’avancement du projet. Cependant cette liberté se doit d’être bornée pour éviter des problèmes de cohérence au sein de la pile logicielle.

Un des principaux objectifs sera ainsi de définir les pratiques de développements et mettre en place une ligne directrice pour le projet. Cela se fera par le choix, en fonction des contraintes du projet, d’un framework (et/ou d’une plate-forme de développement), par le respect de standards de développement et la définition de bonnes pratiques.

Enfin, lors de la définition de votre architecture je vous invite à avoir en permanence la philosophie du rasoir d’Ockham en tête. Saint-Exupéry l’énonce ainsi :

Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher
Antoine de Saint-Exupéry

Ce principe exprime que les solutions les plus simples sont les meilleures, et je vous encourage à rechercher la simplicité dans vos architectures. D’un point de vue plus opérationnel nous pouvons le définir de la sorte :

Les architectures les plus simples sont les plus robustes.

Les outils de l’architecture logicielle

Dans la phase d’architecture, vous devez fournir à l’équipe de développement, une vision technique. Pour ce faire, voici concrètement les outils pour partager celle-ci.

L’utilisation d’UML est déconseillée, elle apporte une rigidité souvent malvenue dans ce type de travaux. Si vous regardez la façon dont vous représentez une architecture, vous verrez que des carrés et des flèches suffisent amplement et je vous invite à continuer dans cette voie d’une représentation simplifiée.

Vos documents d’architecture doivent être visuels et rapidement compréhensibles c’est pourquoi les diagrammes sont la forme la plus conseillée. Personnellement j’utilise les diagrammes suivants :

  • Domain model : il s’agit de représenter les différentes entités métier du projet, leurs rôles au sein du projet et leurs relations. Cela permet d’obtenir une bonne vue du fonctionnement attendu du logiciel et prépare la définition du modèle de données.
  • C4 diagramme : ce diagramme est souvent en réalité deux ou trois diagrammes à différentes hauteurs de vue au niveau logiciel, l’on distingue les niveaux suivants :
    • Contexte, définit l’environnement d’exécution du logiciel : quel sont les éléments avec lesquels il devra interagir (système d’authentification, de logs, etc.)
    • Container : quel sont les grands ensemble métier et technique du logiciel et comment interagissent-ils entre eux (système de facturation, création de document, gestion des usagers, etc.).
    • Composant : sous partie spécialisée d’un container (génération d’une facture, gestion des paiements, etc.)
    • Classes, ce niveau est optionnel et ne doit être utilisé que si il est indispensable de spécifier une implémentation.

A ces éléments, il est généralement ajouté un document texte dans lequel est précisé les éléments suivant :

  • Les spécifications fonctionnelles sous forme de “user stories (fiche wikipedia)”
  • Un glossaire des termes utilisés dans le logiciel
  • Une liste des risques identifiés
  • Les contraintes liées au logiciel
  • La plateforme et/ou le framework à utiliser
  • Un rappel sur les bonnes pratiques

Le rôle de l’architecte

Dans le cadre d’une architecture en “emergent design” l’architecte ne disparaît pas. Il va être en charge de deux aspects amont : limiter au maximum les malentendus et définir la vision technique à l’équipe de développement.

Pour limiter au maximum les malentendus, et préparer au mieux la phase de développement, l’architecte doit affiner les spécifications fonctionnelles en anticipant les questions que pourraient soulever l’équipe de développement. Il en cherchera les réponses auprès du client et/ou du chef de projet.

Pendant la phase de développement, il doit défendre sa vision, rechercher le feedback des développeurs, et les aider à architecturer le logiciel. Il prend alors un rôle de coach pour l’équipe de développement. Le travail d’un architecte ne doit surtout pas se limiter à la phase avant projet, mais réellement accompagner l’équipe sur la durée du développement.

Enfin je rappelle qu’il est très important pour un architecte de se maintenir à niveau, à la fois en élargissant son domaine de compétence via une veille active, mais aussi en continuant à pratiquer le développement afin de garder un sens de la pratique.

Le cas des systèmes complexes

Les systèmes complexes (ou anciens) nécessitent généralement une phase d’architecture d’avant projet plus conséquente. Cependant cela ne doit pas amener à retomber dans les problématiques du “Big Design Up Front” (voir l’article précédent pour plus de détail).

Dans ce cas de figure, la solution consiste à découpler massivement le logiciel : le considérer comme un ensemble de plus petits logiciels spécialisés. Il s’agit alors de définir une architecture de système d’information, seule est définie l’information circulant entre divers composants spécialisés et autonomes. Ces composants sont alors considérés comme des boites noires, et seule les API (les entrés / sorties) sont définies. Chacune de ces parties sera alors conçue en utilisant les mécanismes du design émergent associés à la pratique du “Just Enough Up Front Design”.

L’approche SOA (Service Oriented Architecture) est une mise en œuvre de ce type d’approche : le logiciel est découpé en un ensemble de services spécialisés qui sont composés les uns avec les autres. Le logiciel devient la somme de sous parties indépendantes.

La place de l’UX dans le processus d’architecture

Mon métier consiste principalement à traiter l’architecture d’un point de vue technique, mais l’UX (User eXperience) a une place très importante. Dans l’objectif de limiter les futurs malentendus dans le développement, il est important de faire intervenir ces éléments dans cette partie.

L’UX comprend toutes les interactions que l’utilisateur final aura avec l’outil, l’application ou le site. Les modifications que cela peut entraîner sur le logiciel font que cette réflexion doit être menée à peu près au même moment que la définition de l’architecture.

L’entrée en scène des UX designer se fait au moment où les spécifications fonctionnelles sont dégrossies et lorsque la vision du logiciel commence à se préciser. La phase de design sera l’occasion de valider ou au contraire de modifier l’architecture logicielle imaginée. Il est donc important de faire intervenir cette phase peu après le démarrage de la phase d’architecture.

Sans être nécessaire, et en fonction de la taille du projet, un développeur front (spécialisé sur les technologies d’affichages de l’information) pourra alors livrer une maquette HTML fonctionnelle associée à des planches de styles (ensemble d’éléments unitaire du design: boutons, menus, etc.). Cette maquette sera fournit aux développeurs qui pourront alors commencer d’autant plus vite la phase de développement à proprement parler.

Conclusion

Faites attention à ne pas sur-architecturer un logiciel, ne faites que le strict minimum et le plus simplement possible. Les spécifications d’architecture pouvant se limiter à un document texte associé à 5-6 diagrammes, adaptez le niveau de détail à la taille du projet.

Avec la clôture de la phase avant-projet, le travail de l’architecte ne fait que commencer. Il doit continuer à accompagner l’équipe logiciel pendant tout le cycle de développement du logiciel.

Enfin, il s’agit d’un domaine souvent réservé à des profils spécialisés disposant d’un important background en développement. Et plus important encore, d’une réelle facilité à manipuler des concepts.

Dans la prochaine partie, nous allons nous intéresser aux outils utilisés pour mettre en place la pratique du design émergent, et les écueils à éviter.

Publicités

2 réflexions sur “Concepts de l’architecture logicielle : “just enough up front design”

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s