Fa uns dies vaig començar una sèrie d'apunts blocs sobre el Catalanitzador per a Windows. Avui he pujat al github del projecte una primera documentació inicial de l'arquitectura de l'aplicació ja que penso pot ajudar a altres comunitats lingüístiques que estan mirant d'adaptar el Catalanitzador així com a actuals i futurs col·laboradors. La documentació completa està en anglès però faré cinc cèntims en català.

 

El Catalanitzador és una aplicació client / servidor tradicional: 

Els clients Windows s'executen, serialitzen un XML amb les dades d'execució, que envien al servidor, aquest les procesa i les emmagatzema a una base de dades. Després aquestes dades es poden consultar a través de la pàgina d'estadístiques.

 

L'aplicació per al Windows té al voltant de 15.000 lines de codi. Usa la tipica arquitectura per capes on components de les capes més altes sempre consumeixen els de les capes més baixes:

 

 

 

Patrons de disseny

Durant la implementació he seguit sempre he estat possible els principis de disseny SOLID, malgrat no sempre he estat tot l'ortodox que m'hagués agradat penso que hi ha poques violacions d'aquests principis i les que hi ha són en general justificables. 

 

Una de les decisions inicials era que usaríem proves unitàries, no tinc calculada la cobertura però tenim al voltant de 90 proves unitàries. Molta gent pensa que les proves unitàries són útils per fer proves de regressió (que és cert), però per mi són sobretot un principi de disseny. A l'escriure proves unitàries es garanteixen que les classes tindran acoplament baix. He fet servir poc TDD en general ja que moltes de les classes les tenia que refer cada poc temps a mida que anàvem descobrint noves limitacions d'algunes versions de Windows, paquets d'idioma, etc. TDD requereix molta auto-disiciplina que definitivament no he tingut en la majoria de casos en aquest projecte.

Un dels reptes d'usar proves unitàries en una aplicació que depèn tant del sistema com el Catalanitzador és aïllar aquestes dependències per poder exercitar la lògica de l'aplicació per se. Per això la majoria de funcionalitat del sistema operatiu està encapsulada en classes (registry, XMLParser, Runner, etc) per tal de poder després usar mocking (usant Google Mock que és una virgueria) per simular el comportament de Windows durant l'execució de proves unitàries. Per últim, he empleat també el patró d'injecció de dependències (en aquest cas a través de constructors) per tal obtenir inversió de control en aquests casos.

 

Extensibilitat

 

Un dels principis de disseny del Catalanitzador va ser fer-ho fàcilment extensible. És a dir, disposar d'una mena de sistema de connectors (pluggins) que permetessin de forma senzilla ampliar la funcionalitat i suportar nous programes. El sistema és força senzill, la interfície Action (bé, una classe abstracta ja que amb C++ no en tenen) que un cop implementada permet registrar una nova funcionalitat de forma automàtica. Al crear un nou connector i registrar-lo, automàticament aquest apareix a la interfície d'usuari, es pot escollir i executar, es seralitza el seu contingut, etc. 

 

Ens cal ajuda

Si teniu interès en ajudar en el procés de proves o desenvolupament aquí teniu la informació. Ens cal ajuda!