Projet ASF

Présentation du projet

ASF est un projet des autoroutes du sud de la France. Je ne connais pas la finalité du projet, mais nous développons un outil extrêmement complet permettant de gérer l’humain d’une entreprise de A à Z.

Le fait de mon ignorance du projet global est dû au mode de développement utilisé. Je développe selon des “Specs” que l’on me fournit. C’est un document rédigé en association avec le client, qui permet de décrire ses besoins de façon claire et précise. Chaque écran et chaque fonctionnalité attendue y sont décrits.

Ci-dessous, vous pouvez voir les specs d’un écran que je suis en train de développer.

Elles sont découpées en quatre parties : - la maquette, ce à quoi devra ressembler l’écran final. - les données, qui me permettent de choisir les bons composants à placer sur l’écran. - les règles de gestion, qui décrivent le fonctionnement de l’écran. - les fonctionnalités attendues. Vous voyez ici une petite partie de ces dernières. Il y a en tout 12 règles de gestions pour cet écran. Certaines sont triviales à développer, tandis que d’autres demandent un changement du service de l’application et de sa base de données.

Ce projet possède une architecture complètement différente du projet APM précédent. Le projet, comme il se présente au moment où j’écris ces lignes, est composé de 2156 fichiers, 392 Dossiers pour une taille de 700Mo.

Heureusement, l’architecture de ce projet a été prévue et est adaptée à son envergure. C’est une architecture pour laquelle il m’a fallu plusieurs semaines afin de l’appréhender et de la maîtriser.

L’utilisation intensive de designs patterns a été une source d’apprentissage énorme, qui m’a fait monter en compétence quant à la conception d’un projet. J’ai aussi découvert de nombreux designs patterns qui me seront utiles lors du design d’une future application.

Le projet est découpé en 3 applications fonctionnant indépendamment :

  • Le Business Unit : C’est le cerveau de notre application il gère la base de donnée, les traitements, et transmet des DTO (data transfer object) à l’user interface. (382 fichiers, 42 dossiers, 34Mo)
  • Le Business delegate : C’est un passe plat qui permet d’avoir une interface entre l’user interface et le business unit (1030 fichiers -> la plupart généré automatiquement à partir de l’interface du BU, 150Mo)
  • L’user interface dispose de toutes nos vue, elle implémente un design pattern que l’on a étudié en cours, le design pattern MVC ainsi que beaucoup d’autres (744 fichiers, 132 dossier, 516Mo)

Je n’avais jamais travaillé sur une telle architecture, les changements effectué sur le BU doivent être répercutés jusqu’à l’UI en passant par le BD grâce à un système de version nuget, de DTO, et d’Adapter et Mapper dans le BU et l’UI respectivement. Bref vous l’aurez compris, quand j’ai découvert ça j’étais perdu.

La première fonctionnalité que j’ai eu à implémenter a été rendue en retard. Sur une charge de travail de 4 jours, il m’en a fallu plus de 7.

Voici l’écran fonctionnel, développé d’après les specs que vous avez pu voir plus haut. Il est encore en développement avec la nécessité d’ajouter les pictogrammes comme celui de la loupe.