Actuellement, lors de la programmation d'application utilisant Dynacase, le programmeur est souvent contraint de passer de long moments à chercher l'origine de dysfonctionnement et d'éléments incohérent dans son application, de plus de nombreux retours d'application en phase de test et de pré-production prouve que la phase de déploiement de l'application pourrait être améliorée. Ce document présente tout d'abord une série d'orientation puis de solutions techniques à mettre en place dans une futur version de Dynacase dédiée à l'industrialisation et la viabilisation du produit pour obtenir un environnement qui permet à la fois de prévenir les erreurs de programmation et de guider les développeur lors de la réalisation d'application Dynacase.

Ces travaux sont le préambule à une prochaine évolution de Dynacase ayant pour but d'offrir un atelier de développement. Ils n'apportent pour l'instant aucune nouvelle fonction et se concentre sur l'amélioration de l'existant.

Dynacase étant un boîte d'outil et un moteur pour construire et faire fonctionner des applications métiers, on peut considérer l'ensemble du système comme un système complexe et lui appliquer un ensemble de recommandations qu'on applique couramment aux IHM. Les principes suivants sont donc un point de départ intéressant (extrait de Bastien et Scapin) :

• Gestion des erreurs, des moyens doivent être mis en place pour prévenir et gérer les erreurs du programmeur. Ces moyens sont de trois types :
  • protection contre les erreurs : dès que possible des contrôles sur la cohérence des données doivent être mise en place et si besoin les erreurs doivent être signalées à l'utilisateur.
  • qualité des messages d'erreur : les messages d'erreur de l'application, surtout les messages internes, doivent être les plus significatifs possibles. De plus, ils doivent détailler l'élément en erreur, un correctif possible et une référence vers la documentation adéquate et un numéro d'identification unique permettant un meilleur suivi du problème.
• correction des erreurs : Autant que possible Dynacase doit permettre au programmeur de pouvoir corriger leurs erreurs en détruisant le moins possibles de données
• homogénéité/Cohérence : Une politique de style code doit être mise en place pour faciliter la relecture de celui-ci entre diverses équipes. De plus, le plus possible le même langage de programmation (PHP) doit être utilisé dans toutes les étapes de la vie du produit.
• compatibilité : Il faut qu'il y est un accord entre le langage des programmeurs (programmeur PHP) et l'organisation des sorties, des entrées et du dialogue de Dynacase. Dynacase se doit donc de s'inspirer du fonctionnement des références du milieu du PHP pour améliorer son adoption.

Les chantiers suivants sont mise en oeuvre pour améliorer le processus de production d'une application Dynacase :

• spécification et intégration des familles
• création des cycles de vie
• code PHP
• modules
• architecture

La spécification des familles est l'élément central de Dynacase, c'est de cette étape que dépend le paramétrages de l'ensemble de Dynacase et la cohérence du code. Cette étape doit donc être fiabilisée pour permettre le moins possible d'erreurs et d'incohérence.

La déclaration de la famille comporte des éléments obligatoire, optionnel. Obligatoire :

• nom logique
• titre
• version
• type

Optionnel

• icône
• profil par défaut
• profil de document par défaut
• fichier PHP de méthode associé à la famille
• cycle de vie par associé à la famille
• contrôle de vue associé à la famille
• caractéristique de révision spécial

Lorsqu'un attribut a été déclaré les éléments suivants sont obligatoires pour l'attribut :

• identifiant de l'attribut
• nom de l'attribut
• type de l'attribut
• ordre de l'attribut
• visibilité de l'attribut
• booléen indiquant le caractère obligatoire de l'attribut

Les éléments suivants sont optionnels :

• booléen indiquant l'appartenance au titre
• booléen indiquant l'appartenance au résumé
• hyperlien
• fichier d'aide à la saisie associé
• fonction d'aide à la saisie, ou attribut calculé, ou énuméré
• extra lien
• méthode contrainte
• options de présentation

L'absence des éléments obligatoires produit une ERREUR.

L'élément permettant de décrire la famille (XML ou ODS) doit être fournis avec a minima un élément permettant de vérifier la cohérence et aidant à la saisie des différents éléments le composant. Pour l'ODS : les fonctions de l'ODS lui même seront utilisés pour aider à la saisie et un script sera utilisé pour vérifier les contrôles décrits dans “Contrôle de syntaxe” Pour le fichier XML : un fichier XML Schema sera fourni permettant de vérifier la syntaxe du fichier.

Quelque soit le mode d'importation choisi, un ensemble de contrôles doivent être appliqués lors de tout import. Les résultats d'un des contrôle unitaire sont de trois types :

• Erreur : résultat bloquant qui aboutit à l'arrêt de l'import
• Alerte : résultat non bloquant qui n'aboutit pas à l'arrêt de l'import
• Valide : contrôle valide

Cet ensemble de contrôle doit toujours donner lieu à un rapport détaillé indiquant par famille :

• la liste des contrôles effectués et leurs résultats
• la liste des éléments importés (attributs et préférence) et la réussite ou l'échec de l'importation

Les contrôles sont de deux types :

• syntaxe : contrôles pouvant être effectué sans Dynacase
• cohérence : contrôles devant être effectué avec Dynacase

Le rapport est à la fois présenté via l'IHM qui a servi à l'import (soit dynacase-control, soit CLI) et stocké dans un fichier de log dédié à cet usage. Lors de l'importation d'une famille des test seront effectués au preImport (contrôle de syntaxe) et au postImport (contrôle de cohérence) de la famille, ces tests sont décrits ci-dessous.

Le nom logique d'une famille doit être obligatoire et vérifier la syntaxe suivante : uniquement des caractères alphabétique en majuscule et le caractère _. L'échec de ce contrôle aboutit à une “Erreur”. Ce contrôle sera effectué grâce à l'expression régulière suivante : [A-Z_]+

Le nom d'une famille doit être obligatoire. L'échec de ce contrôle aboutit à une “Erreur”. Ce contrôle sera effectué en vérifiant la présence de la chaine.

Le contrôle de cohérence du nom logique de la famille doit être appliqué au nom logique de la famille dont on hérite. L'échec de ce contrôle aboutit à une “Erreur”. Ce contrôle sera effectué grâce à l'expression régulière suivante : [A-Z_]+

Si les éléments suivants sont présents :

• dossier par défaut
• profil de famille
• profil de document
• cycle de vie
• contrôle de vue

alors ils doivent suivre la syntaxe suivante : uniquement des caractères alphabétique en majuscule et le caractère _. Ce contrôle sera effectué grâce à l'expression régulière suivante : [A-Z_]+

Le paramétrage de l'auto-révision de la famille ne doit pas être obligatoire et peut avoir une des deux valeur suivantes : R, S L'échec de ce contrôle aboutit à une “Erreur”. Ce contrôle sera effectué grâce à l'expression régulière suivante : [RS]{0,1}

Le nom logique d'un identifiant d'attribut/paramètre est obligatoire et doit vérifier la syntaxe suivante : uniquement des caractères alphabétique en minuscule et le caractère _. De plus, ce nom doit faire entre 1 et 60 caractères. L'échec de ce contrôle aboutit à une “Erreur”. Ce contrôle sera effectué grâce à l'expression régulière suivante : [A-Z_]{1,60}

Le nom logique d'un identifiant de frame d'un attribut/paramètre doit vérifier la syntaxe suivante : uniquement des caractères alphabétique en minuscule et le caractère _. De plus, ce nom doit faire entre 0 et 60 caractères. L'échec de ce contrôle aboutit à une “Erreur”. Ce contrôle sera effectué grâce à l'expression régulière suivante : [A-Z_]{0,60}

Les élément suivants :

• attribut présent dans le titre
• attribut présent dans la fiche résumé
• attribut obligatoire

ont pour valeur soit Y soit N. L'échec de ce contrôle aboutit à une “Alerte”. Ce contrôle sera effectué grâce à l'expression régulière suivante : [YN]{0,1}

L'élément indiquant la visibilité d'un attribut doit avoir une valeur comprise dans l'énuméré suivant : W R H O S U I
L'échec de ce contrôle aboutit à une “Erreur”.
Ce contrôle sera effectué grâce à l'expression régulière suivante : [WRHOSUIL]{0,1}

Le nom des fichiers PHP attachés à la famille (fichier méthode et fichier d'aide à la saisie) ne doit pas être obligatoire et vérifier la syntaxe suivante : .*.php
L'échec de ce contrôle aboutit à une “Alerte”.
Ce contrôle sera effectué grâce à l'expression régulière suivante : .*.php

Le nom d'une fonction attachée à un attribut doit être de la forme suivante : ::(non obligatoire) nom de fonction PHP valide (ensemble de caractères ASCII commençant par un caractère alphabétique ou _) ( ensemble de nom d'attribut (voir SIF_SYN_06 sont aussi autorisé les annotations “CT”, “D”) séparés par des ”,” (sans espace) ): ensemble de noms d'attributs (voir SIF_SYN_06) auquel peut-être préfixé “i_ink” séparé par des ”,”
L'échec de ce contrôle aboutit à une “Erreur”.
Ce contrôle sera effectué grâce à une expression régulière

Le nom d'une contrainte attachée à un attribut doit être de la forme suivante : ::nom de fonction PHP valide (ensemble de caractères ASCII commençant par un caractère alphabétique ou _) ( ensemble de nom d'attribut (voir SIF_SYN_06 sont aussi autorisé les annotations “CT”, “D”) séparés par des ”,” (sans espace) )
L'échec de ce contrôle aboutit à une “Erreur”.
Ce contrôle sera effectué grâce à une expression régulière (à définir)

Les options d'attributs doivent obéir à la règle suivante : chaine de caractères alphanumériques (avec _)=chaine de caractères alphanumérique (avec _) séparé par “|” sans espace.
L'échec de ce contrôle aboutit à une “Alerte”.
Ce contrôle sera effectué grâce à une expression régulière (à définir)

Le numéro d'ordre d'un attribut doit être un entier.
L'échec de ce contrôle aboutit à une “Alerte”.
Ce contrôle sera effectué grâce à une expression régulière suivante : [0-9]+

Le type d'un attribut doit être un des éléments suivants : text longtext htmltext frame date time timestamp password file image nteger double money enum docid(”[ID_DE_FAMILLE]”) docid color ifile idoc menu
L'échec de ce contrôle aboutit à une “Erreur”.
Ce contrôle sera vérifié à l'aide d'une comparaison dans un dictionnaire.

Si la famille référence une famille père un contrôle de l'existence de celle-ci doit être effectué.
L'échec de ce contrôle aboutit à une “Erreur”.

Lorsque la famille hérité d'une famille ,un contrôle doit être effectué pour vérifier qu'aucun des attributs de la famille n'a le même nom logique qu'un des attributs de la famille père.
L'échec de ce contrôle aboutit à une “Erreur”.

Lorsque la famille hérité d'une famille ,un contrôle doit être effectué pour vérifier que tous les attributs hérités de la famille sont bien définis dans la famille père.
L'échec de ce contrôle aboutit à une “Erreur”.

Si les éléments suivants sont présents, alors ils doivent être existant : Dossier par défaut

• Profil de famille
• Profil de document
• Cycle de vie
• Contrôle de vue

L'échec de ce contrôle aboutit à une “Erreur”.

Si les éléments suivants sont présents, alors ils doivent être compatible avec la famille :

• Dossier par défaut
• Profil de famille
• Profil de document
• Cycle de vie
• Contrôle de vue

L'échec de ce contrôle aboutit à une “Erreur”.

Les fichiers PHP référencés (fichier méthode et fichier fonction) doivent être présents.
L'échec de ce contrôle aboutit à une “Erreur”.

Les fichiers de layout référencés doivent être présents.
L'échec de ce contrôle aboutit à une “Erreur”.

Si un fichier icône est notifié alors il doit être présent dans le répertoire image.
L'échec de ce contrôle aboutit à une “Alerte”.

Les fonctions référencés doivent être présentes dans les fichiers les contenants (fichier méthode pour les fonction en :: et fichier référencé pour les autres).
L'échec de ce contrôle aboutit à une “Erreur”.

Les attributs référencés dans les méthodes doivent être présentes dans la famille (via la déclaration ou l'héritage).
L'échec de ce contrôle aboutit à une “Erreur”.

Si un link/elink commence par %S% et contient les mots clefs action et app alors l'application et les actions référencées doivent exister.
L'échec de ce contrôle aboutit à une “Alerte”.

Le numéro d'ordre d'un attribut doit être unique dans sa famille.
L'échec de ce contrôle aboutit à une “Alerte”.

Tout attribut de type non structurant (tous les types sauf frame, menu, tab) doit être contenu dans un attribut de type frame ou array (sauf si l'attribut est lui même un array dans ce cas il doit être contenu dans une frame).
L'échec de ce contrôle aboutit à une “Alerte”.

Un nom logique d'attribut doit être unique dans sa famille.
L'échec de ce contrôle aboutit à une “Alerte”.

Test sur l'existence de la famille référencée par un attribut de type docId.
L'échec de ce contrôle aboutit à une “Alerte”.

Test sur l'existence de la famille référencée par la copie et de l'attribut copié dans cette famille.
L'échec de ce contrôle aboutit à une “Erreur”.

Test sur l'existence de la famille référencée par la copie et de l'attribut copié dans cette famille et du type énuméré de cet attribut.
L'échec de ce contrôle aboutit à une “Alerte”.

Test sur l'existence de l'attribut et sur la cohérence de la valeur par défaut en fonction du type de l'attribut.
L'échec de ce contrôle aboutit à une “Alerte”.

Si le lien du menu commence par %S% et contient les mots clefs action et app alors test de l'existence de la fonction appelée. Si la fonction n'existe pas Dynacase vérifie qu'elle ne fait pas partie des fonctions ajoutées par l'importation de la famille
L'échec de ce contrôle aboutit à une “Alerte”.

Le mécanisme de spécification et d'importation de famille est appliqué aux cycles de vie.

Une norme de codage doit être appliquée à l'ensemble du produit Dynacase. Cette norme doit permettre d'augmenter la fiabilité de l'application en rendant le code plus lisible et plus constant entre les différents programmeurs et la communauté intervenant sur le projet.

Le code produit doit être compatible avec le niveau E_NOTICE (verbosité PHP) ⇒ error_reporting(E_ALL|E_NOTICE)

Le code de Dynacase doit être modifié pour prendre en compte une spécification de codage.

Avant toute commit de source du projet, un outil d'évaluation du code sera passé sur l'ensemble des sources commités et refusera le commit si l'ensemble des règles de codages ne sont pas respectées. En cas de refus, l'outil indiquera :

• la ligne de où il y erreur
• l'erreur

Dynacase ne doit pas être sensible à la casse sur les éléments sur les noms logiques des différents éléments qui lui sont propres (document, famille, attribut, paramètre). les attributs sont référencés par des constantes de classe (et non plus des chaînes de caractères).

Dynacase doit fournir deux type de méthode :

• Les méthodes internes qui ne sont qu'à usage de Dynacase et sont indiqués comme tel dans l'API de Dynacase sur lesquels la maintenance et la compatibilité est indiquée, ces méthodes seront préfixés par la mention INT_
• les méthodes externes qui sont à usages des applications externes et sont indiqués comme tel dans l'API de Dynacase

Les attributs d'une classe ne doivent être accessibles directement, des getteurs/setteurs sont mis en place.

Dynacase doit présenté deux types de gestions des cas d'erreurs:

• les erreurs de codage : lors d'une erreur due à une utilisation erronée d'une fonction, référence à un élément (attribut, famille, …) inexistant ⇒ production d'une erreur PHP
• les erreurs de fonctionnement ⇒ lors d'une erreur due à l'impossibilité de résoudre l'élément dans les conditions actuel ⇒ production d'une exception PHP

Pour résumer le mode de fonctionnement :

• les erreurs PHP sont destinées aux programmeurs dans le cadre de la réalisation de son projet
• les exceptions PHP sont destinées au code pour permettre au programme de gérer un mode de fonctionnement dégradé de l'application.

Lors de l'utilisation d'une famille non existante une erreur spécifique doit être levée

Lors de l'instanciation d'un document non existant une exception spécifique doit être levée

Lors d'une demande pour un attribut non existant une erreur spécifique doit être levée

Lors d'une demande pour un paramètre non existant une erreur spécifique doit être levée

Lors de la tentative de modification d'un attribut non existant une erreur spécifique doit être levée

Lors de la tentative de modification d'un attribut sur un document non alive une exception spécifique doit être levée

Lors de la tentative de modification d'un attribut vers une valeur non valide sur un document une erreur exception spécifique doit être levée

Lors de la tentative de modification d'un paramètre non existant une erreur spécifique doit être levée

==(PHP_ERR_09) Modification d'un paramètre sur une famille non alive== Lors de la tentative de modification d'un paramètre sur une famille non alive une exception spécifique doit être levée
un famille existe ou n'existe pas

Lors de la tentative de modification d'un paramètre vers une valeur non valide sur un document une erreurexception spécifique doit être levée

==(PHP_ERR_11) Modification d'une propriété vers une valeur non valide== Lors de la tentative de modification d'une propriété vers une valeur non valide sur un document une erreur spécifique doit être levée les propriétés ne sont pas accessibles

==(PHP_ERR_12) Modification d'une propriété d'un document non alive== Lors de la tentative de modification d'une propriété sur un document non alive une exception spécifique doit être levée Idem PHP_ERR_11

Lors de la tentative de modification de l'état d'un document vers un état non valide une erreur spécifique doit être levée si l'état n'est pas déclaré ⇒ ERREUR, si l'état demandé n'est pas conforme à la logique du cycle ⇒ EXCEPTION

Lors de la tentative de modification de l'état d'un document non alive une exception spécifique doit être levée

Lors d'une recherche sur une famille non existant une erreur spécifique doit être levée

Lors d'une recherche sur un attribut non existant dans la famille en cours de recherche une erreur spécifique doit être levée

Dynacase doit être capable de gérer différent types de logs et différents niveau de logs. Les types de log à gérer sont :

• applicatif : élément loguant le déroulement fonctionnel de l'application (import de données, log spécifique à l'application en cours etc…)
• technique : élément loguant les erreurs et le déroulement technique de l'application

Ces niveaux de log doivent être paramétrables pour être plus au moins verbeux.

Les logs technique doivent avoir 5 niveaux de logs :

• info : Dynacase enregistre les données de son fonctionnement interne
• erreur : Dynacase trace les erreurs PHP, les erreurs postgresql et les exceptions Dynacase (ce mode est toujours activé)
• avertissement : Dynacase trace les lancements d'exception
• debug : Dynacase trace les éléments indiqués comme devant être tracés en mode debug
• trace : Dynacase trace tout le fonctionnement de l'application (toutes les entrées dans toutes les fonctions avec paramètres et sortie)

Le paramétrage des niveaux d'erreur pour un contexte doit être accessible dans dynacase-control et dans le module de gestion de ce contexte

L'emplacement et le type des logs doivent être paramétrables dans dynacase-control et dans le module de gestion de ce contexte. Les log sont accessibles depuis dynacase-control, pour chaque contexte.

En mode debug, toutes les fonctions permettant de modifier la valeur d'un attribut ou d'un paramètre ou d'un attribut (au sens objet du mot) doivent être tracés avec la pile d'appel à cet élément. Les méthodes impactées sont les suivantes :

• setValue
• addArrayRow
• 

En mode debug, toutes les fonctions permettant d'acquérir la valeur d'un attribut ou d'un paramètre ou d'un attribut (au sens objet du mot) doivent être tracés avec la pile d'appel à cet élément. Les méthodes impactées sont les suivantes :

• getValue
• getAValues
• 

En mode debug, les appels à toutes les fonctions méthodes d'un document seront tracés avec l'ensemble des paramètres passés en argument, la pile d'appel à cette méthode et les valeurs sortantes. Les fonctions impactées sont les suivantes :

• verifyAllConstraint
• preCreated
• add
• postCreated
• specRefresh
• Refresh
• specRefreshGen
• postModify
• modify
• preDelete
• delete
• postDelete
• preCopy
• postCopy
• preImport
• postImport
• preConsultation
• preEdition
• 

En mode debug, les appels à toutes les fonctions définies dans le cadre d'une famille (attribut calculé, contrainte et aide à la saisie) seront tracés avec la pile d'appel à cet élément, les valeurs entrantes et les valeurs sortantes.

En mode debug, les appels à toutes les actions devront être tracées avec la liste des valeurs entrantes, l'URL d'appel, l'IP d'appel et le user d'appel.

Toutes les familles obsolètes ou inutiles devront êtres supprimées, ainsi que toutes les références à des attributs plus utilisé (forum par exemple)

La documentation de l'API doit être facilement accessible que ça soit online offline et utiliser le template le plus adapté à une lecture facile. De plus, l'API de Dynacase doit être documentée et les fonctions appelées en CLI doivent donner un exemple de cas d'utilisation si elles ne sont pas appelées avec les bons arguments

La documentation de l'API doit être téléchargeable au format HTML

La documentation de l'API doit être téléchargeable au format PDF

La documentation de l'API doit comprendre un moteur de recherche permettant a minima de rechercher parmi les fonctions de tous les modules de l'API

Toutes les fonctions de l'API CLI doivent être documentées et avoir une chaine d'usage explicitant le nom des arguments attendu et les paramètres attendu