Développement d'applications de gestion avec UML

Pierre Loisel - mars 2001

1. Solution d'implémentation et réalisation d'une application "test"

2. Etude fonctionnelle et réalisation du logiciel comptable

3. Bilan de l'expérience

Télécharger l'ensemble du dossier (1,7 Mo environ) : umldelphipl.zip

1. Solution d'implémentation

a. But de l'étape

Définir comment il est possible d'implémenter un diagramme de classes correspondant à une application de gestion dans un produit comme delphi en essayant de respecter les contraintes suivantes :

• Au niveau analyse, les classes sont du type "entité", c'est-à-dire qu'elles correspondent à des objets à mémoriser dans une base de données.
• Au niveau technique, il est impératif de séparer les trois composantes fondamentales d'une application de gestion
• L'interface
• Les traitements
• Les données
• Les composants delphi standards d'accès aux données doivent être utilisables dans la solution retenue (dans le cas contraire, la solution ne serait pas réaliste en terme de temps de développement et perdrait son intérêt).

b. Une reflexion préalable

Le document prelable.doc présente une première expérimentation intitulée "UML, client/serveur et outils de développement". Le but est simple : comment passer d'une classe "entité" à une application distribuable.

Au sommaire : quatre versions de cette "application miniature", allant d'une implémentation classique à l'aide des composants DELPHI, jusqu'à une implémentation 3-tiers utilisant la technologie DCOM.

c. La solution retenue

Cette réflexion préalable m'a conduit à penser qu'il valait mieux utiliser les composants d'accès aux données en les spécialisant pour les adapter au problème. Le schéma de principe de l'articulation des classes nécessaires à la réalisation d'une application est le suivant :

• Chaque classe "entité" découverte en phase d'analyse est implémentée à l'aide d'une table et d'un contrôleur d'entité qui encapsule tous les accès aux données.
• Un ensemble de contrôles applicatifs gèrent tous les traitements réalisés par l'application.
• Un ensemble d'objets interface (fiche ou report) s'occupent de l'aspect présentation en utilisant les services des contrôleurs applicatifs et des contrôleurs d'entité.

Le fonctionnement est décrit à travers un exemple permettant de gérer un ensemble d'employés et de services.

Le document Implémentation.doc décrit la solution dans le détail :

• Il précise de quelle manière il est possible de passer d'un diagramme de classes UML à une application DELPHI.
• Il décrit le projet "uml.dpr" fournissant les composants de base qu'il est possible de réutiliser.
• Il détaille un exemple pratique d'utilisation de la méthode d'implémentation (projet empSce.dpr).

uml.zip

Ce fichier contient l'ensemble du projet fournissant les composants de base permettant de simplifier la réalisation d'une application. Pour l'utiliser, il suffit de les intégrer au référentiel de Delphi comme décrit dans le document "implementation.doc".

empSce.zip

Contient l'ensemble du projet empSce.dpr illustrant la solution d'implémentation retenue. La base de données interbase utilisée est également dans le dossier.

Pour l'utiliser sans problème, il faut que le dossier "uml" soit situé au même endroit que le dossier "empSce" (ou modifier le chemin d'accès à "cu_controleur.pas" dans le programme principal.

2. Réalisation du logiciel comptable

a. Analyse

Diagramme de contexte

Diagramme des cas d'utilisation

Diagramme de classes d'analyse

L'application a été développée en trois itérations réalisant successivement les cas d'utilisation suivants :

• Gestion du plan de comptes et saisie des écritures
• Consultation des résultats
• Travaux de fin d'exercice

b. Exemple de la première itération

Cas d'utilisation saisie des écritures

Interface utilisateur prévue

Diagramme de classes de conception

Les classes préfixées par TF correspondent à des classes d'interface utilisateur (fiches), celles préfixées par TC à des classes contrôleur d'entité, celles préfixées par TE à des classes entité. Une classe contrôle applicatif (préfixée TA) sera ajoutée en phase de réalisation.

c. Compte-rendu

L'application complète implémente les fonctionnalités suggérées par ce menu principal :

Les fichiers suivants constituent un compte-rendu complet de ce développement :

umlCompta.doc

Ce document contient un compte-rendu d'analyse et de conception d'un logiciel comptable s'appuyant sur la notation UML et la solution d'implémentation retenue.

Compta.zip

Contient l'ensemble du projet compta.dpr illustrant la solution d'implémentation retenue. La base de données interbase utilisée est également dans le dossier.

Pour l'utiliser sans problème, il faut que le dossier "uml" soit situé au même endroit que le dossier "compta" (ou modifier le chemin d'accès à "cu_controleur.pas" dans le programme principal.

3. Bilan de l'expérience

La caractéristique la plus importante en terme de conséquences me paraît être la séparation interface/traitement/données plutôt que l'utilisation d'UML et d'un processus unifié pour la réalisation de l'application.

Les choses peuvent paraître un peu complexes au premier abord. Le mieux est de consulter les sources de l'exemple fourni et d'essayer.

Les avantages à attendre d'une solution de ce type sont les suivants :

• Bonne traçabilité, la solution d'implémentation respecte scrupuleusement l'analyse et la conception.
• Le code est regroupé en deux endroits : les classes contrôleurs (il s'agit du code correspondant aux méthodes des classes d'analyse), et la (ou les) classe(s) applicatif(s) (il s'agit du code représentant la logique de l'application).
• On ne trouve plus des "petits morceaux" de logique de programme disséminés derrière les boutons de chaque formulaire de l'application, ce qui est extrêmement bénéfique du point de vue de la maintenance.
• Ce principe devrait être très facilement adaptable à la technologie MIDAS (outil de réalisation d'applications distribuées) et donc permettre une implémentation en client/serveur multi-niveaux.
• La réutilisation des objets métiers est plus facile car leur codage est clairement localisé en terme de fichiers sources.

Les inconvénients sont les suivants :

• J'ai eu l'impression très forte de développer de manière quelque peu exotique !
• La démarche me semble difficile à présenter à nos étudiants de BTS informatique.
• Il convient d'adapter ces principes de base à chaque environnement de développement utilisé (cela me semble envisageable avec tous les produits "sérieux" du marché).

En conclusion, ne sais pas si cette expérimentation est utilisable dans le cadre de mes enseignements, mais elle a été indiscutablement enrichissante. N'hésitez pas à me contacter par mail pour échanger sur ce thème...

Télécharger l'ensemble du dossier (1,7 Mo environ) : umldelphipl.zip

_____________________________________________  
© - Réseau C E R T A 
Ministère de l'éducation nationale, de l'enseignement supérieur et de la recherche