1er EPISODE : La Modélisation

Pour ce premier numéro, nous allons nous focaliser sur la modélisation, correspondant aux phases de Spécifications détaillées et de Conception technique.

Généralités

Une bonne Modélisation permet :

• Une génération possible d'une partie du code (Phase de développement >)
  
• Une capitalisation du métier dans un format standard (UML) et indépendant des choix technologiques en aval (J2EE, .Net, ...)
  
• Une optimisation des temps & délais de recette
  
• Une diminution des charges de maintenance corrective (sur les bugs fonctionnels)
  
  

Le langage standard de modélisation de système à base d'objets est UML (Unified Modeling Language).

UML est un support de communication :

• Sa notation graphique permet d'exprimer visuellement une solution objet,
  
• L'aspect formel de sa notation limite les ambiguïtés et les incompréhensions,
  
• Son aspect visuel facilite la comparaison et l'évaluation de solutions,
  
• Son indépendance (par rapport aux langages d'implémentation, domaine d'application, processus, etc...) en font un langage universel
  
  

Méthodologie

Cependant UML n'est qu'un langage et pas une méthode.

Il convient alors d'adopter une méthode de modélisation en fonction :

• De l'architecture logicielle sur laquelle reposent les projets
  
  • Construire un profil d'analyse cohérent
    
• De la taille des projets
  
  • Définir le niveau de conception et les tâches associées
    
    

L'architecture logicielle faisant référence à ce jour est l'architecture N-Tiers qui consiste à séparer les composantes d'une application en couches spécialisées :

• Présentation : Elle comprend les composants permettant la présentation ou la saisies d'information à un acteur du système,
  
• Dynamique Applicative (Navigation) : Elle comprend les composants permettant de :
  
  • contrôler les informations saisies,
    
  • appeler les services métiers nécessaires à la réalisation de l'activité sollicitée,
    
  • aiguiller, en fonction des résultats des appels aux services métiers, vers les activités nécessaires
    
• Services métiers : Elle implémente les composants appliquant les règles métiers (règles de gestion à proprement dire),
  
• Persistance des données : Elle implémente les composants permettant de stocker les données du système.
  
  
  

Il est nécessaire de mettre en place un « Profil d'Analyse » (Définition de stéréotypes et d'attributs étendus permettant de modéliser avec UML des objets « particuliers ») adapté à ce type d'architecture.

Ce profil d'analyse « type » les différents objets UML afin qu'ils représentent individuellement les différents composants d'une application.

Par exemple :

• les IHMs d'une application sont représentées par des Interfaces et des classes possédant des stéréotypes dédiés :
  
  • « Page » pour la composition d'une page en plusieurs blocs
    
  • « IHM_FORM » pour un bloc de page du type formulaire de saisie d'information
    
  • « IHM_TAB » pour un bloc de page du type liste de données – etc.).
    
• les Services métiers sont représentés par des classes possédant un stéréotype « COMPOSANT »,
  
• les actions d'un contrôleur par une activité de stéréotype « Action »,
  
• etc.
  
  

La finesse de modélisation (et donc la précision du Profil d'Analyse) dépend des objectifs d'industrialisation que veut atteindre le client.

On peut déterminer cinq niveaux de finesse de modélisation et donc trois objectifs d'industrialisation :

• Aucune : Les projets ne sont pas modélisés (La spécification est faite sous forme littéraire sans structuration particulière.
  
• RAD : Les projets sont modélisés de façon minimaliste (On s'arrête à la conception générale). Le Design de l'application est dans le code. Cette typologie de couplage Modélisation-Coding correspond à une méthodologie RAD (Rapid Application Developement) qui prévoit N itérations de codage-recette pour arriver aux résultats attendus (S'envisage pour des petits projets au fonctionnel simple réalisés en interne)
  
• Externalisation : Ici les projets sont modélisés de façon à ne pas laisser d'ambiguïté quand au fonctionnel à réaliser (On s'arrête à la conception détaillée). Cette typologie de modélisation convient particulièrement bien pour une stratégie d'externalisation des développements dans un contexte de projets périphériques au système d'information.
  
• Legacy : Ici les projets sont modélisés de façon à ne pas laisser d'ambiguïté tant au niveau fonctionnel qu'au niveau technique (On va jusqu'à la conception technique). Cette typologie de modélisation s'applique dans le cadre de projets faisant partie du cœur du système d'information et qu'il convient d'urbaniser.
  
• Génération : Ici les projets sont non seulement modélisés jusqu'à la conception technique mais en plus l'effort de précision est tel que la modélisation traduit l'architecture logicielle sur laquelle repose les projets. Cette typologie de modélisation s'applique dans le cadre d'une volonté de minimiser au mieux les efforts de coding. Le patrimoine applicatif du système d'information se retrouve au niveau des conceptions et plus de la technologie de développement (implémentation). Les cas les plus courants d'implémentation sont les clients dont le fonctionnel est stable mais dont le métier induit des refontes techniques régulières (Ouverture de son système à l'extérieur - Echange d'informations vers client - etc.) ou dont la structure informatique est réduite et composée pour l'essentiel de chef de projet - Analyste fonctionnel.
  
  
  

L'effort de développement (proportionnellement à celui de la conception) dépend bien évidemment du niveau de conception comme le montre le graphique suivant :

Enfin, nous préconisons par ailleurs de définir différentes étapes de modélisation, correspondant aux découpage des activités de modélisation en vues (ou perspectives) qui permettent de définir de façon globale le système (PERSPECTIVE GLOBALE)

puis d'entrer au fur & à mesure dans le détail (PERSPECTIVE FONCTIONNELLE)

et enfin d'aller jusqu'à la conception technique (PERSPECTIVE METIER & PERSISTANCE).

Bien évidemment chacune de ces phases peut être produite en cohérence avec un phasing projet (Analyse générale ou Cahier des charges – Spécifications détaillées – Conceptions techniques).

Exemple

Sans entrer dans les détails, voici un exemple de « Perspective Globale » qui a déjà été mise en œuvre chez nos clients :

Cette perspective a pour objectif de définir :

• les fonctionnalités à réaliser par le système
  
• les acteurs interagissant avec le système
  
• les droits des acteurs sur les fonctionnalités du système,
  
• la charte graphique du système
  

Elle consiste à produire 5 diagrammes de USE CASE :

· Le USE CASE DES ACTEURS (UC ACTEUR) :

Il s'agit ici de définir les acteurs "humain" en terme de "métier" (définition des PROFILS) et de leur positionnement dans l'organisation de l'entreprise

· Le USE CASE DES FONCTIONS (UC FONCTION) :

Il s'agit ici de définir les fonctions à réaliser par le système

· Le USE CASE D'HABILITATION (UC HABILITATION) :

Il s'agit d'associer les acteurs du type personne physique ou élément de structure d'organisation avec les fonctions définies précédemment pour décrire les droits d'interaction.

· Le USE CASE D'INTERFACE (UC INTERFACE) :

Il s'agit d'associer les acteurs du type d'élément du système d'information avec les fonctions définies précédemment pour décrire les interfaces à réaliser.

· Le DIAGRAMME DE CLASSE CHARTE ERGONOMIQUE (DC CHARTE)

Il s'agit de décrire la charte ergonomique des pages composants la couche de présentation du système à réaliser.

Conclusion

En résumé, la mise en place d'une méthodologie de modélisation est très impactante sur la suite du projet et il est nécessaire de bien prendre en compte tous ces paramètres pour définir la solution optimale, suffisamment complète sans toutefois être trop luxueuse.

Rendez vous dans notre prochain numéro pour le deuxième épisode dans lequel nous nous intéresserons à la phase de développement.

Marc TABARY