Memoire Online - Conception et Developpement d'un logiciel de gestion commerciale

Tache	Durée	Pourcentage
Etude préalable	5 jours	10%
Conception	15 jours	30%
Développement	20 jours	40%
Rédaction du rapport	10 jours	20%

5.5 Conclusion :

Dans ce chapitre on a présenté en premier lieu quelques modèles du cycle de vie d'un logiciel. On a justifié notre choix sur le modèle de référence qu'on a choisi (prototypage).

Vu le grand nombre des interfaces composant notre application, en second lieu on s'est contenté de donner quelques unes qui nous paraissent plus importantes. On a essayé au maximum possible présenter une seule interface s'il y' a plusieurs ayant des similarités. Et à la fin, on a donné un tableau résumant le déroulement du projet.

o de nous perfectionner en améliorant nos connaissances en programmation et en conception.

o De bien comprendre et mettre en oeuvre le déroulement d'un cycle de vie d'un logiciel.

Nous avons essayé de réaliser ce projet pour le but de faciliter l'entreprise en question, d'améliorer la gestion et le suivi de ses clients, de ses fournisseurs et de son stock.

On a appliqué au maximum possible les règles de bases permettant d'avoir une application performante. Nous avons appliqué UML pour concevoir une grande partie de notre travail. Nous avons utilisé aussi Java et Access pour implémenter notre application.

Grâce aux architectures que nous avons utilisé (MVC et client/serveur) et du fait que Java est un langage adaptable dans plusieurs domaines, notre application peut avoir des extensions ou des modifications dans le futur. Citons quelques unes :

o On peut lier cette application à un site web dynamique qui nous permettra le suivi des clients et des fournisseurs en ligne.

o On peut changer le SGBD au cas où l'entreprise aura des données volumineuses à stocker.

o Dans l'avenir quand l'entreprise aura besoin de plusieurs agents travaillant en même temps en réseau, on peut utiliser le concept Remote Method Invocation (RMI) : appels des méthodes à distant

KELLER, Nicolas ROUQUET, Maxime. - KellerRouquet [ FORMTEXT en ligne ], 03/03/2006.

GHARSALLI Alia et BEN AMMAR Amel. - Conception et développement d'une application de gestion de société de services. - Projet de fin d'études, ISIMM.

Le diagramme des cas d'utilisation qui fait partie des modèles dynamique d'UML2 sert entre- autre un moyen de communication entre les spécialistes et le client, et d'un outil nous permettant d'avoir une idée sur les principales interfaces de l'application.

UML n'emploi pas le terme d'Utilisateur mais d'acteur. Les acteurs d'un système sont les entités externes à ce système qui interagissent avec lui. Quand on dit « qui interagissent », on veut dire qui envoient des évènements comme, cliquer sur un bouton OK ou encore envoyer un fichier de données ou une trame XML. On veut aussi dire qui reçoivent des informations de la part du système comme, recevoir une facture, mettre à jour un référentiel de données ou encore mettre à jour une application back-office.

Les acteurs sont donc à l'extérieur du système et dialoguent avec lui. Ces acteurs permettent de cerner l'interface que le système va devoir offrir à son environnement. Oublier des acteurs ou en identifier de faux conduit donc nécessairement à se tromper sur l'interface et donc la définition du système à produire. On fera attention à ne pas confondre acteurs et utilisateurs d'un système. Non pas que cela soit faux car tout dépend du sens donné au mot utilisateur mais trop souvent, le mot utilisateur est vu comme un raccourci pour désigner ceux qui vont cliquer dans les fenêtres de l'application. Les acteurs sont plus que les « simples » utilisateurs humains d'un système. D'une part parce que les acteurs inclus les utilisateurs humains mais aussi les autres systèmes informatiques ou hardware qui vont communiquer avec le système.

Pour trouver les acteurs d'un système, on va identifier quels sont les différents rôles que vont devoir jouer ses utilisateurs. Car les acteurs sont en fait les rôles joués par ces différents Utilisateurs (ex : Responsable clientèle, Responsable d'agence, Administrateur, Approbateur,...). On regardera ensuite quels sont les autres systèmes avec lesquels le système va devoir communiquer soit en mode réception soit en mode émission d'évènements (ex : Hardware d'un distributeur de billet, Système d'information partenaire, ERP,...).

Un biais classique dans l'identification des acteurs est dû au fait que les acteurs peuvent aussi être d'autres systèmes. Aussi, il est fréquent de vouloir identifier comme acteur les référentiels de données existant dans le système d'information. Effectivement, le

Système à produire aura sûrement à récupérer ou à mettre à jour des données issues de ces référentiels, mais le risque d'identifier ces systèmes comme acteur est qu'ensuite, lors de la rédaction des cas d'utilisation, on risque de rentrer trop tôt dans la solution et oublier l'expression première du besoin. Je ne dis pas qu'identifier ce type d'acteur est une erreur fondamentale mais l'expérience montre que l'intérêt est minime et que les biais induits sont néfastes : une description des cas d'utilisation plus proche de la solution que du besoin.

Les cas d'utilisation vont ici nous aider à décrire ces attendus. On entend souvent que les cas d'utilisation permettent de décrire les fonctionnalités attendues du système de point de vue des acteurs. Ce n'est pas faux mais attention car «fonctionnalités» se transforme souvent en « fonctions ». On en arrive donc à utiliser les cas d'utilisation pour faire un découpage fonctionnel au sens procédures des langages procéduraux. Et là, on se trompe complètement d'objectif.

Ces fonctionnalités que l'on documente avec les cas d'utilisation doivent avoir un sens pour le métier des acteurs. Pour identifier les cas d'utilisation, il faut donc se poser les questions :

?? « Mais que va faire cet acteur avec le système en arrivant le matin au boulot ? »

En se posant ce type de question, on verra que généralement des cas d'utilisation comme «Rechercher client » ou « Imprimer facture » ne sont pas des cas d'utilisation mais plutôt des fonctions du système. L'important avec les cas d'utilisation est de bien décrire ce que l'on pourrait désigner savamment par « unité d'intention complète ». C'est-à-dire une série d'envois d'évènements de la part de l'acteur au système et de réponses du système pour atteindre un objectif métier précis. Et non les différentes fonctions du système qui seront en fait déduites des différents cas d'utilisation.

· Une description résumée permettant de comprendre l'intention principale du cas d'utilisation. Cette partie est souvent renseignée au début du projet dans la phase de découverte des cas d'utilisation.

· Des acteurs déclencheurs : ceux qui vont réaliser le cas d'utilisation (la relation avec le cas d'utilisation est illustrée par le trait liant le cas d'utilisation et l'acteur dans un diagramme de cas d'utilisation)

· Des acteurs secondaires : ceux qui ne font que recevoir des informations à l'issue de la réalisation du cas d'utilisation (Ex : client ou autre système informatique. La relation avec le cas d'utilisation est illustrée par le trait liant le cas d'utilisation et l'acteur dans un diagramme de cas d'utilisation)

· Des pré-conditions qui décrivent dans quel état doit être le système (l'application) avant que ce cas d'utilisation puisse être déclenché (Ex : un contrat existe avec le client).

· Des scénarii. Ces scénarii sont décrits sous la forme d'échanges d'évènements entre l'acteur et le système. On classe les scénarii en : Un scénario nominal (celui qui est déroulé quand il n'y a pas d'erreur, celui qui est principalement réalisé dans 90% des cas), des scénarii alternatifs qui sont les variantes du scénario nominal et enfin les scénarii d'exception qui décrivent les cas d'erreurs.

· Des post-conditions qui décrivent l'état du système à l'issue des différents scénarii (Ex : un contrat est créé et le système back-office est mis à jour avec le nouveau contrat créé)

· Des informations sur l'utilisation du cas d'utilisation comme : le nombre de personnes exécutant ce cas d'utilisation dans une journée type, le nombre d'objets

(métiers !) traités par le cas d'utilisation dans une journée type (Ex : 120 contrats créés

Eventuellement une description des besoins en termes d'interface graphique. Ce chapitre étant réservé à des cas simples car généralement traité en dehors de la description même du cas d'utilisation. Dans ce cas une cohérence doit d'ailleurs être assurée entre l'IHM et la description du cas d'utilisation.

UML définit 3 grands types de relations entre cas d'utilisation : généralisation/spécialisation, include, extends.

Il est important de noter que l'utilisation de ces relations n'est pas primordiale dans la rédaction des cas d'utilisation et donc dans l'expression du besoin. Ces relations peuvent être utiles dans certains cas mais une trop forte focalisation sur leur usage conduit souvent à une perte de temps ou à un usage faussé, pour une valeur ajoutée, au final, relativement faible.

La relation « d'extend » est probablement la plus utile car elle a une sémantique qui a un sens du point de vue métier au contraire des 2 autres qui sont plus des artifices d'informaticiens.

On dit qu'un cas d'utilisation X étend un cas d'utilisation Y lorsque le cas d'utilisation X peut être appelé au cours de l'exécution du cas d'utilisation Y comme :

Ce type de relation est primordial pour l'écriture de l'application. Imaginer dans le cas précédent que l'on n'ait pas mis la relation « extends ». Cela signifierait que lors de la prise de commande pour un nouveau client, le processus de prise de commande devrait être annulé au moment de la saisie des informations client, pour d'abord exécuter « Enregistrer client » afin que le client soit connu puis ensuite, reprendre le processus de prise de commande depuis le début ; pas cool pour notre responsable clientèle et bonjour l'image commerciale donnée au client !

La relation d'include n'a pour seul objectif que de factoriser une partie de la description d'un cas d'utilisation qui serait commune à d'autres cas d'utilisation. Le cas d'utilisation inclus dans les autres cas d'utilisation n'est pas à proprement parlé un vrai cas d'utilisation car il n'a pas d'acteur déclencheur ou receveur d'évènement2. Il est juste un artifice pour faire de la réutilisation d'une portion de texte.

Une erreur classique est d'utiliser la relation « d'include » pour faire du découpage fonctionnel d'un cas d'utilisation en plusieurs « sous cas d'utilisation » qui s'enchaînent en fonction de certains critères. On en arrive alors à se demander : Comment documenter l'enchaînement des sous cas d'utilisation avec UML ? Mais cette question n'a en fait pas lieu d'être, tout simplement.

Cette relation est de mon point de vue la relation la plus discutable du point de vue de son utilité pratique. Elle consiste à dire que l'on a un cas d'utilisation dit « de base », générique, qui décrit des séquences d'évènements et d'autres cas d'utilisation qui héritent de ce comportement de base et le spécialise suivant différents critères (le comment de la chose reste nébuleux). On pourra par exemple avoir une situation comme

On espère vous avoir un peu éclairé sur cette espèce que sont les cas d'utilisation et surtout sur leur bon usage. On espère aussi que vous aurez compris qu'il est inutile de compliquer leur utilisation en introduisant la notion de relation et que les cas d'utilisation deviennent « simples » si on s'en tient à répondre à la question : Mais est ce que ce cas d'utilisation à un sens du point de vue métier pour l'acteur, n'est ce pas une vision informaticienne de son besoin ? Les détails d'informaticiens seront abordés lors des activités d'analyse et de conception.

Annexe 2 Règles de passage du modèle conceptuel au modèle physique (MCD MLD)

Table et clé primaire :

Toute classe ou entité (=objet de gestion) est transformée en table. Les attributs de l'entité deviennent les attributs de la table. L'identifiant de la classe/entité devient la clé primaire de la table.

Conception et Developpement d'un logiciel de gestion commerciale

5.4 Déroulement du projet :

5.5 Conclusion :

Table et clé primaire :