Modéliser une architecture logicielle grâce aux modèle C4 ou C4 model en anglais

C'est quoi la modélisation d'une architecture logicielle à l'aide du modèle C4 ? Je connaissais bien UML et l'outil qui va avec Enterprise Architect alors C4 c'est quoi ? 

C4 c'est l'abréviation de Context, Container, Component and Code. Par rapport à UML qui donne différents moyens pour décrire l'architecture, l'approche C4 c'est d'introduite une notion de zoom avant et arrière suivant le niveau de détails que l'on veut avoir sur une modélisation du projet.

J'ai déjà vu cela quelque part il y a bien longtemps (30 ans environ) il existait un logiciel comme cela sur Macintosh qui permettait de "descendre" et de "remonter" dans la description d'un projet... Aujourd'hui ce serait un logiciel pour créer des Cartes Mentales.

Donc C4 Model c'est un peu comme le DDD une approche descente de la conception pour raffiner son niveau de connaissance du système à modéliser. Je vais très vite car en vérité tout cela ne m'amuse pas beaucoup. 

Simplement j'ai trouvé une description de poste à pourvoir avec "connaissance de la modélisation C4 impérative". Et je souris intérieurement d'imaginer tous ces gens faire de beaux petits dessins sans savoir où cela les mène. Comme c'est le cas avec de nombreuses "modélisations".


L'outil : Structurizr

Structurizr
L'outil Structurizr pour modéliser votre architecture logiciel en modèle C4

Oui, c'est assez confus, sur le site également, certainement un outil dans lequel il faut investir en découverte et en connaissance. Disons que c'est le seul à parler de décomposition d'architecture en modèle C4.

Contexte

Description du contexte de l'utilisateur en situation, on dirait la description des cas d'utilisation en UML.

Conteneur

On raffine les grandes boîtes que l'on a dessinées au niveau du contexte. Tout est là, c'est la grande idée du modèle C4 comme de beaucoup de méthodologies de spécification. Vous pouvez ainsi faire une décomposition de votre architecture que vous ferez évoluer avec vos connaissances.

Composant

On raffine chacun des Conteneurs que l'on décompose en composants.

Code

Ils parlent de diagramme de classes UML. Moi j'opterai pour une description en pseudo code.

Conclusion

C'est du déjà vu, c'est même une façon de faire de la conception et pas tellement de la spécification, le raffinage des différents blocs de fonctionnalités c'est clairement de la conception. Peut-on spécifier avec ce modèle ? Vous verrez que dans les bonnes pages que le mot spécification n'est pas utilisé.

Les bonnes pages :

C4 model : LA solution pour les diagrammes d'archi ?
Vous n'en apprendrez pas plus.

Pour approfondir l'architecture en microservices et le DDD :

Architecture modulaire, microservices : on en est où ?
Le métier d'abord le découpage en microservices et un travail métier et non technique. Permet de revoir le DDD. Après le CCCC le DDD ;-)

Et pour aller plus loin rien de mieux que la source :

Microsoft - Concevoir une application orienté microservices
Là c'est du lourd, complet extrêmement détaillé, voyez le dessin :

Architecture en Microservices

Architecture en Microservices


Ce n'est pas du modèle C4, mais ça les vaut largement en matière de description de modélisation d'architecture ! En un regard on a une vision complète et synthétique du logiciel comme sur une véritable carte.

C'est incroyable, il y a Simon Brown qui prétend détenir la licence du modèle C4 licence CC BY 4.0 ça me rappelle mais cours de méthodologie logicielle, il y a trente ans lorsque l'on avait subit au sein de la SAGEM une formation obligatoire où l'on apprenait à dessiner des boite et des flèches, cette formation avait du durer 3 jours ! Et à la fin pareil une licence d'utilisation du modèle MEF ?!

Avec mes collègues, on se regardait et on se faisait la même réflexion, cette formation nous apprend à dessiner des boites et des flèches ! Pendant trois jours !

A l'époque cela pouvait peut-être se justifier, le logiciel était quelque chose de nouveau et d'un peu magique que nos managers souhaitaient qu'on leur explique, d'une façon ou d'une autre. Donc on a appris nombre de modèle de spécification conception etc... merise et autres.

Aujourd'hui il y a une absolue nécessité de spécifier un logiciel, un SI. Il faut écrire pour combien d'utilisateurs à qui, pourquoi, comment et puis faire une conception pour répondre aux spécifications. Les moyens de description sont innombrables alors il faut simplement choisir le plus adapté.


C'est quoi la rétrospective d'équipe dans le cadre de la méthodologie Agile ?

La réunion de rétrospective d'équipe qui a lieu à la fin de chaque Sprint permet de garantir le respect du processus d'amélioration continue. C'est cette réunion qui permet à chacun de faire le point sur son expérience du sprint qui vient de s'écouler et ceci afin d'améliorer l'efficacité de toute l'équipe.

L'amélioration continue est un processus qui n'est pas seulement dans l'Agile mais qui doit être une préoccupation de toutes les équipes de développement. À ce titre il faut "mesurer" savoir où l'on en est, pour être certain que l'on s'améliore et que l'on est capable de mesurer cette amélioration.

Et je trouve le très bon site de l'Agiliste sur ce sujet :

L'Agiliste - L'art de la Rétrospective
Comment dérouler une réunion de rétrospective, ce que j'aime c'est que l'on ne cherche pas à juger, on ne cherche pas à trouver de coupable, on cherche juste à établir un état des lieux, une prise de conscience de soi pour que chacun puisse s'améliorer. 

SOAT Blog - La rétrospective : qui ? quoi ? comment ?
C'est un moment de partage avec un jeu le "Safety check" :


Un jeu permet à chacun de s'exprimer de façon non verbale, d’extérioriser quelque chose même pour les plus timides.

Je pense qu'il est important que tout le monde s'exprime donne son ressentiment. Pour être certain d'assurer une amélioration continue de l'ensemble de l'équipe en globalité.

Voilà, je me devais de faire ce focus sur la "réunion de rétrospective" dans le cadre méthodologie agile, dans le cadre de l'amélioration continue, sans dérouler la totalité de la métho agile.