ELEMENTS D'UNE DEMARCHE SPECIFIQUE A L'ETUDE ET AU DEVELOPPEMENT DE SYSTEMES DINFORMATION TRANSPORT

Livrable 5.2. du projet TRAFIC

Transports : Rutilisation, Adaptation, Fiabilit, Intermodalit et Coopration inter-systmes

Projet de la Rgion Rhne-Alpes 2003-2005 Thmatiques prioritaires Thme 6 : Aide la dcision Transports

Auteurs : Nicolas Arnaud, Agns Front, Jean-Pierre Giraudin. Date : Dcembre 2005

TABLE DES MATIERES

Table des Matires ............................................................................................................................... 2 Introduction.......................................................................................................................................... 3 Partie A Dmarche et processus de dveloppement........................................................................ 6 1 Processus de dveloppement en Y......................................................................................... 6 2 Dmarche itrative incrmentale ........................................................................................... 6 3 Dmarche pilote par les cas dutilisation ............................................................................. 7 4 Dmarche oriente composant mtier.................................................................................... 8 Partie B Phases de spcification des besoins, danalyse et danalyse de la coopration ................ 9 1 Spcification des besoins ..................................................................................................... 10 2 Spcification organisationnelle des besoins ........................................................................ 14 3 Analyse ................................................................................................................................ 16 4 Analyse de la coopration.................................................................................................... 17 Partie C Phases darchitecture applicative, technique et cooprative ........................................... 18 1 Architecture applicative ....................................................................................................... 18 1.1 Description des couches applicatives.............................................................................. 18 1.2 Etablissement de la cartographie des composants techniques ........................................ 19 1.3 Description des composants et des classes techniques ................................................... 20 1.4 Dfinition des rgles de conception et de transformation............................................... 20 2 Architecture technique ......................................................................................................... 20 3 Architecture cooprative...................................................................................................... 21 Partie D Phase de conception ........................................................................................................ 22 1 Transformation vers le langage Java.................................................................................... 22 2 Intgration avec le gnrateur de la socit ACTOLL ........................................................ 25 Partie E Conclusion....................................................................................................................... 27

INTRODUCTION
La mthode de dveloppement de systmes dinformation transport dveloppe dans le cadre du projet TRAFIC est largement inspire de la mthode Symphony, une mthode de dveloppement logiciel lorigine labore et industrialise par la socit Umanis1 en collaboration avec l'quipe SIGMA du laboratoire LSR-IMAG. La mthode Symphony a pour but de spcifier les diffrentes phases dun projet de dveloppement de systmes dinformation et de dfinir les tches de chacun des intervenants. Il sagit dune dmarche itrative, incrmentale, oriente utilisateur, oriente composant mtier et pilote par les cas dutilisation. Elle adopte un modle de cycle de vie en Y permettant de sparer ltude des besoins fonctionnels (les fonctions attendues de lapplication pour rpondre aux besoins du mtier de lentreprise) de celle des besoins techniques (les contraintes oprationnelles de lapplication telles que les contraintes matrielles et logicielles, la qualit de service en terme de temps de rponse, la tolrance aux pannes, etc.) et ceci ds le dbut du cycle de vie des applications. Cela permet une meilleure analyse du problme et des risques, mais aussi une meilleure rutilisation de lexistant. Ainsi, le modle de cycle de vie de la mthode Symphony prsent dans la Figure 1 sarticule autour de 3 branches. La branche fonctionnelle (gauche) correspond la tche traditionnelle de modlisation du domaine et des besoins des utilisateurs. Les rsultats de lanalyse ne dpendent daucune technologie particulire et se rsument un modle de composants mtier. La branche technique (droite) a pour objectif le recensement des contraintes et des choix techniques ncessaires pour la conception du systme tels que la scurit, la monte en charge, lintgration lexistant, etc. Ces lments permettent, par la suite, llaboration des architectures applicatives et techniques de lapplication. Larchitecture applicative spcifie les composants techniques et le framework technique mettre en place pour supporter lexcution des composants mtier. Larchitecture technique dcrit larchitecture matrielle et rseau du systme de production. On y dcrit la rpartition des logiciels sur les machines physiques ainsi que les protocoles de communication des diffrents nuds de larchitecture. Cette laboration est accompagne par lidentification des rgles de conception et des patrons dont lobjectif est de pallier aux manques de la technologie. La branche centrale est une intgration des branches fonctionnelle et technique. Elle permet de raliser une conception intgrant le modle danalyse dans larchitecture applicative de manire obtenir un modle de conception traant les composants du systme dvelopper. Ce modle de conception est par la suite traduit dans un langage de programmation en utilisant les outils de dveloppement choisis dans la branche technique. Les tests unitaires des composants sont raliss au fur et mesure que leurs units de code sont dveloppes. La phase de recette permet de tester fonctionnellement lapplication en suivant le cahier des charges pralablement rdig. La phase de dploiement consiste enfin mettre en production lapplication teste techniquement et fonctionnellement.

http://www.umanis.com

Exigences Fonctionnelles

Etude pralable

Exigences Techniques

Cahier des charges gnral

Conception cooprative Implmentation Intgration Recette

DEPLOIEMENT Dploiement

GPI

Figure 1 : Cycle de vie en Y de la mthode Symphony

Les rsultats obtenus dans les lots 2, 3 et 4 du projet TRAFIC nous ont conduit modifier la mthode Symphony en laugmentant de nouvelles phases spcifiques aux SIT, en particulier ltude de la coopration entre systmes dinformation transport qui joue un rle prpondrant dans le cadre de lintermodalit des transports o de nouveaux systmes doivent pouvoir cooprer avec les systmes anciens. Ainsi, la nouvelle mthode UP-TRAFIC (cf. Figure 2) est compose dun ensemble de phases dans lesquelles sont intgrs les patrons, les composants et les technologies dvelopps dans le cadre du projet TRAFIC : les composants mtiers dvelopps dans le cadre du lot 2 constituent comme dans la mthode Symphony, le mcanisme essentiel utilis lors des phases de spcification des besoins et danalyse, les approches coopratives dveloppes dans le cadre du lot 3 font lobjet de nouvelles phases : - la phase danalyse de la coopration o les patrons danalyse de la coopration prsentent les diffrents modes possibles de coopration, - la phase darchitecture cooprative intgrant les patrons darchitecture asynchrones, les patrons de protocoles et les patrons synchrones, - la phase de conception de Symphony est augmente et renomme en phase de conception cooprative utilisant les patrons de conception qui reprsentent le rsultat de lintgration des composants mtiers dans les architectures spcifies dans les patrons darchitectures, - enfin la phase dimplantation utilise des patrons de support technique ddis aux plates-formes distribues telles que J2EE. En particulier, dans le cadre de la socit ACTOLL, elle permet dintroduire en entre du gnrateur les composants mtiers issus de la phase danalyse. les travaux sur les requtes visuelles et sur laccs progressif dvelopps dans le cadre du lot 4 constituent des composants techniques particuliers au domaine des SIT et sont utilisables lors de la phase darchitecture applicative.

Ar ch Te itect chn ur iqu e e

Ar c Ap hitec pli tur cat e ive

on ati f ic n s ci soi Sp s Be de se aly An

Exigences Fonctionnelles

Etude pralable

Exigences Techniques

Cahier des charges gnral

Ar ch Te itect chn ur iq u e Ar e c Ap hitec pli tur cat e i ve

Composants mtier m transport (lot 2)

Composants et Patrons danalyse d de la coopration coop (lot 3) Patrons de conception (lot 3)

Ar c Co hitec op ra ture tiv e

Comme la dmarche Symphony, la dmarche UP-TRAFIC s'appuie sur le langage unifi de modlisation UML. Elle a pour but de dvelopper des applications volutives dans le domaine des systmes dinformation transport et de rduire leurs cots de dveloppement, de dploiement, dexploitation et de mise jour tout en mettant un fort accent sur ltude de la coopration et de linteroprabilit entre les systmes. Les sections correspondantes sont les suivantes : dmarche et processus de dveloppement : prsentation de la dmarche, du processus de dveloppement et de son cycle de vie en Y, phases de spcification des besoins, danalyse et danalyse de la coopration : description des phases et des activits formalisant les exigences mtier, phases darchitecture applicative, darchitecture technique et darchitecture cooprative : description des phases et des activits formalisant les exigences techniques, en particulier au niveau applicatif, le besoin ou non dun langage dinterrogation visuelle ou dun accs progressif linformation, et dun point de vue technique, phases de conception cooprative et dimplantation : description de la phase et des activits associes.

on ati fic oins ci Sp s Bes de a ly An se

Composant technique Langage visuel (lot 4)

Composant technique Accs Progressif Acc (lot 4)

Figure 2 : dmarche UP-TRAFIC, positionnement des lots

la de se n a ly tio An pra co o

Conception cooprative Implmentation Intgration Recette

Patrons techniques de coopration coop (lot 3)

Patrons de support technique (lot 3)

Partie A Dmarche et processus de dveloppement

1 Processus de dveloppement en Y

UP-TRAFIC propose un processus de dveloppement itratif, organis au travers d'un certain nombre de cycles de dveloppement en Y (cf. Figure 2). Chaque cycle de dveloppement, appel aussi itration, est centr sur un processus mtier ou le raffinement d'un processus mtier identifi, dcrit et pondr lors de la phase d'tude pralable. Un cycle de dveloppement est une instanciation de la succession des diffrentes phases du processus.

Dmarche itrative incrmentale

Un cycle de dveloppement peut tre lui-mme dcompos en d'autres cycles si le processus mtier qu'il reprsente est lui mme dcomposable. Dans ce cas, selon leur complexit et leur priorit, de nouvelles tapes d'tude pralable sont inities avec en entre un processus mtier dcomposer. Une itration est donc centre sur un processus mtier ou le raffinement d'un processus mtier. L'enchanement de plusieurs cycles de dveloppement aboutit progressivement au produit logiciel final. Le processus global itratif de la dmarche UP-TRAFIC relve comme celui de la mthode Symphony d'un nouveau type de cycle de vie gnralisant le cycle de dveloppement en Y : le modle en flocons. La Figure 3 prsente de manire dtaille la gnralisation de ce modle au processus de dveloppement UP-TRAFIC. Le dveloppement est ainsi fond sur la croissance et l'affinement successif d'un systme par le biais d'itrations et d'incrments multiples. Lintgration de la vision mtier seffectue dans chaque itration de dveloppement. Le rsultat de chaque itration est un systme test, intgr et excutable, mais incomplet et non encore prt tre livr (un incrment). Le dploiement dans un environnement de production ncessite plusieurs itrations. Le rsultat nest pas non plus un prototype2. En revanche, il reprsente un sous-systme du systme final et rpond un sous-ensemble des spcifications du systme. Pratiquement, pour chaque itration, il convient de choisir un ensemble dexigences mtier puis de les concevoir, de les implmenter et de les tester rapidement. Lors des premires itrations, les choix fonctionnels et techniques ne correspondent pas forcment au rsultat final souhait. Mais le fait de commencer la ralisation avant que les spcifications soient compltement finalises ou que la totalit de la conception ait t pense permet dobtenir rapidement un retour dvaluation des utilisateurs, des dveloppeurs et aussi des testeurs. Le cas chant, ce retour dinformation permet la remise en cause de lexactitude des spcifications ou de la conception.

Le dveloppement itratif nest pas une activit de prototypage.

Figure 3 : dmarche UP-TRAFIC, processus de dveloppement itratif incrmental

Lavancement du projet dpend des retours dvaluations des diffrents sous-systmes rsultats issus des diffrentes itrations. Lutilisateur final dispose ainsi de la possibilit dvaluer rapidement le systme partiel et de donner ou non son approbation selon quil sagisse ou non de fonctionnalits attendues du systme final. Ainsi son avis intervenant en amont du processus constitue un bon moyen de dcouvrir en dbut de projet ce qui est rellement important pour lui.

Dmarche pilote par les cas dutilisation

La dmarche est oriente utilisateur et pilote par les cas dutilisation. En effet, elle intgre les besoins et les usages rels des utilisateurs ds les phases amont du dveloppement. Ces besoins sont alors modliss par des cas dutilisation qui assurent la cohsion des activits et guident le processus de dveloppement dans son ensemble. Les modles de cas dutilisation dcrivent les fonctionnalits compltes du systme. A partir de ces modles, les concepteurs crent une srie de modles de conception et de dveloppement ralisant les cas dutilisation. Les testeurs vrifient si les composants mtier logiciels dvelopps respectent correctement les cas dutilisation. Les besoins des utilisateurs sont donc prioritairement traits dans la branche gauche et la branche droite du modle en Y. Les cas dutilisation constituent un mcanisme essentiel de traabilit entre modles. Pour apporter des lments de rponse aux problmes et contraintes dvolution du systme et de ses besoins mtier et technique, lquipe de dveloppement doit tre en mesure de naviguer dans lensemble du systme et de pouvoir remonter dun modle un autre pour faciliter la propagation des modifications. Cette deuxime forme de traabilit est garantie par les liens entre les diffrents lments des modles.

Dmarche oriente composant mtier

La dmarche UP-TRAFIC est oriente Composant Mtier (CM) car lapplication est vue, tant au niveau conceptuel que logiciel, comme un assemblage de CM indpendants et interconnects. Cette pratique garantit une bonne modularit des spcifications et facilite leur rutilisation. Les CM sont reprsents selon le modle conceptuel de composants mtier Symphony, tel que prsent dans le livrable 2.2 du lot 2. Vis--vis dun acteur extrieur, un CM correspond une entit quil peut manipuler. Cette entit est apte excuter des oprations et matrise des informations qui lui permettent dassumer des oprations quelle sengage raliser. Les informations forment un rseau de concepts qui a un sens pour le mtier. Les parties suivantes se concentrent sur chaque branche du cycle de vie en Y de la dmarche UP-TRAFIC, en commenant par les phases de modlisation mtier, danalyse et danalyse de la coopration (branche fonctionnelle), puis les phases darchitecture applicative, darchitecture technique et darchitecture cooprative (branche technique) et en terminant par la phase de conception cooprative (branche centrale). Pour des raisons de place, les phases succdant la conception ne sont pas dcrites dans ce livrable.

Partie B Phases de spcification des besoins, danalyse et danalyse de la coopration

Lobjectif de Symphony en tant que dmarche base de composants mtier est de conduire les acteurs du processus de dveloppement du systme produire une structure (cartographie) de CM dont le couplage est le plus faible possible. Ces CM doivent supporter lensemble des services attendus par le mtier gnrateur de la demande de dveloppement. . Dans notre exemple, le dcoupage fonctionnel global permet de recenser deux PM : Gestion du Voyage et Gestion des Usagers . Gestion des usagers : oprations relatives aux personnes et leurs cartes qui ne concernent pas le transport directement (achat de titre de transport, achat de carte, etc.) Gestion du voyage : oprations ayant trait au voyage, validations des titres de transports, comptage des validations, etc.

Ce dcoupage fonctionnel global est issu de notre collaboration avec la socit ACTOLL. Nous nous intressons plus particulirement au PM Gestion des Usagers de priorit 1. Ce PM traite des oprations ayant trait aux usagers et leurs titres de transport (achat de titre, achat de cartes, etc.).

Figure 4 : tude pralable, modle des processus mtier

Un des buts de la phase dtude pralable est aussi didentifier les acteurs internes et externes afin de comprendre la finalit attendue par chaque acteur du systme. Il sagit alors de rpondre aux questions suivantes : pour qui, pour quoi, dans quelles conditions, comment et quels rsultats ? La Figure 5 montre la classification des acteurs internes et externes obtenue en rponse ces questions. Elle identifie par exemple lusager comme acteur externe dclencheur des processus Gestion des Usagers et Gestion des Voyages, alors que lautorit organisatrice qui souhaite obtenir des informations statistiques sur les voyages est un acteur externe secondaire. Le guichetier, les validateurs dans les bus et les transporteurs sont considrs comme des acteurs internes qui devront interagir avec le systme informatique dvelopper.

Figure 5 : tude pralable, diagramme des acteurs mtier

Spcification des besoins

Cette phase correspond lidentification des finalits de chaque PM identifi prcdemment. Il sagit de dcrire le quoi , de se focaliser sur les objectifs et contraintes du processus li aux acteurs externes en faisant abstraction des contraintes dorganisation et des acteurs internes au processus. La spcification conceptuelle des besoins comprend les activits suivantes pour chaque PM : description conceptuelle de chaque PM sous la forme dun scnario principal3 mettant en vidence les interactions entre acteurs externes et PM, les pr et post conditions, description conceptuelle formelle de chaque PM laide dun diagramme de squence conforme au scnario tablit dans lactivit prcdente, dcomposition en Processus Mtier Composants (PMC) le cas chant. Sur notre exemple, le but est donc de dcomposer les deux processus mtiers dfinis prcdemment, cest dire la Gestion des Usagers et la Gestion du Voyage en plusieurs PMC (Processus Mtier Composant). La Figure 6 montre les processus mtiers composants permettant de rpondre lensemble des oprations ncessaires la gestion des usagers et des voyages dans un SIT. Gestion des Usagers : o Gestion des abonnements : concerne les achats de nouveaux abonnements pour des nouveaux ou anciens clients ne possdant pas de carte. o Gestion des vols/pertes de carte : ventuellement un changement de carte avec remplacement des titres prsents sur lancienne carte et qui nont pas encore t valids. o Gestion du changement de carte lorsque la carte nest plus valide (une fois la date de validit expire ou en cas de disfonctionnement). o Gestion des achats de titre : lopration la plus courante pour un S.I.T aprs la validation. Gestion du Voyage : o Gestion des validations : simple validation, avec toutes les modifications que cela implique (aussi bien sur la carte quau niveau de lhistorisation). o Gestion des comptes : ce processus mtier composant est utilis pour connatre le nombre dusagers ayant utilis une borne prcise, ceci afin de grer les remboursements entre les diffrentes socits de transports.

Un scnario principal est le cas nominal. Il sagit souvent du chemin normal dexcution du processus [KET 01]. Il nimplique pas les flux alternatifs ou les flux derreur.

10

Figure 6 : Processus mtiers composants - Gestion des Usagers et Gestion des Voyages

Ltape suivante consiste pour chaque processus mtier composant, dfinir et reprsenter dans un diagramme de squence, son vnement dclencheur, les acteurs externes participants, les pr-conditions, un scnario dexcution, et les post-conditions.

11

Par exemple, le PMC Gestion des abonnements est dfini de la faon suivante : Gestion des abonnements Evnement dclencheur : Emission de la Demande dAbonnement. Acteur Externe : Usager. Pr-condition : aucune. Scnario : - Lusager met une Demande dAbonnement. - Le PGU (Processus de Gestion des Usagers) met un avis de prise en charge. - Le PGU met la facture. - Le PGU transmet la carte. La personne est maintenant considre comme Usager et possde une carte dabonnement valide.

12

Comme nous le voyons sur le diagramme de squence, le processus mtier composant Gestion des Abonnements peut lui-mme tre dcompos en deux processus mtiers composants : Contrler Demande d'Abonnement : vnement dclencheur : Emission d'une Demande d'Abonnement. Acteur externe : Usager. Pr-condition : Aucune. Scnario : - Emission dune Demande dAbonnement (D.A.) - Vrifier que la D.A est correcte et que l'usager ne possde pas dj une carte. o Si les informations sont errones ou que l'usager possde dj une carte : refus. o Sinon : transmettre l'assur une facture pour le rglement de sa carte. Post-conditions : - Si l'usager n'a pas de contrat et si les informations sont correctes, on met une facture - Sinon, on lui transmet un avis de refus en expliquant le motif.

Facturer service dabonnement vnement dclencheur : Transmission rglement. Acteur externe : Usager. Pr-condition : Lusager a reu sa facture. Scnario : - L'usager rgle la facture. o Si le paiement n'est pas correct : on transmet l'usager un refus ainsi que son motif. o Sinon, on accde sa demande (rechargement de carte, transmission de sa carte dabonnement, etc.) Post-conditions : - Lusager a reu ce quil dsirait ou un avis de refus.

13

La dcomposition en PMC est rgie par les flux externes. Un PMC lmentaire est donc ininterruptible : il est dclench par un flux externe et se droule sans interruption jusqu mission de rsultats. Cette dcomposition est similaire celle prconise dans Merise/2 [PAN 94] pour dterminer les activits dans un modle de flux conceptuels ou les oprations dun Modle Conceptuel de Traitements (MCT). Dans le cas dun vnement temporel, l horloge correspond un acteur externe. Chaque PMC est ensuite dcrit, en spcifiant son scnario, ses pr et post conditions ainsi que son diagramme de squence en tenant compte, cette fois-ci, des diffrents flux alternatifs. Cette activit est suivie par un bilan permettant de spcifier si les PMC sont eux mmes dcomposables ou pas. Si cest le cas et que le PMC est assez complexe, une nouvelle phase dtude pralable complte est dmarre. En revanche, pour un PMC dcomposable non complexe, on reprend lactivit de description conceptuelle formelle du PMC pour effectuer sa dcomposition. Dans le cas dun PMC non dcomposable, on enchane sur la phase de spcification organisationnelle des besoins.

Spcification organisationnelle des besoins

Dans cette phase, il sagit de dcrire qui fait quoi et quand . Lobjectif est de prendre en compte les choix de lorganisation en faisant intervenir les acteurs internes identifis dans la phase dtude pralable. La spcification organisationnelle des besoins comprend les activits suivantes pour chaque PMC : dcomposition organisationnelle des PMC en fonction de la rpartition des processus entre acteurs internes et de la distinction entre les processus informatiss et ceux manuels, gnration et mise en relation des cas dutilisation partir de Processus Mtier Informatiss (PMI) et sous la forme dun diagramme de cas dutilisation, tablissement de la cartographie des CM Processus ralisant les cas dutilisation.

14

Dans notre exemple, la dcomposition organisationnelle des deux PMC Contrler Demande dAbonnement et Facturer Service donne lieu un diagramme dactivits (cf. figure suivante) montrant lacteur interne Guichet ainsi que lenchanement des processus mtiers informatiss et manuels.

Figure 7 : spcification organisationnelle des besoins, dcomposition organisationnelle de PMC

Le diagramme des cas dutilisation rsultant (cf. Figure 8) prend en compte tous les PMI (un cas dutilisation pour chaque processus). La figure suivante montre lensemble des processus informatiss ralisables par les acteurs internes pour les deux PM Gestion des Usagers et Gestion des Voyages. Lactivit Emission Carte de Transport constitue par exemple un cas dutilisation dclench par lacteur (interne) Guichet .

15

Figure 8 : spcification organisationnelle des besoins, cas d'utilisation

Analyse

Lobjectif de la phase danalyse consiste mettre en vidence ce que doit faire le systme sans tenir compte de la manire de le raliser. Il est question de modliser le comportement et la structure des CM Processus, Entit et Donnes de rfrence, sachant que les CM dj identifis correspondent plus des CM Processus, chargs de raliser un certain nombre de cas dutilisation. La phase danalyse permet didentifier et de modliser de nouveaux CM de type Entit et Donnes de rfrence. Le modle danalyse rsulte dune analyse dynamique (oriente diagrammes dynamiques UML) puis dune analyse structurelle (oriente diagramme statiques UML). Pour lanalyse dynamique, les activits sont les suivantes : formalisation de haut niveau du scnario principal de chaque cas dutilisation fonctionnel, formalisation dtaille du scnario principal et des scnarii secondaires de chaque cas dutilisation, description des cycles de vie des CM, modlisation du comportement4 (pour les scnarii complexes), dfinition des contrats doprations. Les activits de lanalyse structurelle sont les suivantes : modlisation des interfaces des CM (classe interface de chaque CM),
La modlisation du comportement concerne les CM Processus complexes. Les activits complexes sont alors dcomposes en sous-activits dont lenchanement des activits (squence, conditions, paralllisation) doit tre prcis et formalis (par des diagrammes dactivits par exemple).
4

16

modlisation des collaborateurs (classes rle de chaque CM), description des CM (en langage naturel), tablissement des relations inter CM (via les classes rle ). laboration de la cartographie des CM (Processus, Entit et Donnes de rfrence). Par souci de simplicit, nous ne prsentons pas toutes les tapes qui nous ont permis daboutir la cartographie des 9 composants mtiers mis en uvre dans les processus mtiers Gestion des Usagers et Gestion des Voyages. Ces 9 composants ont t prsents en dtail dans les livrables 2.2 et 2.3. Nous rappelons uniquement dans le tableau ci-dessous leur brve description. Composant Client Description Composant principal, dsigne les personnes clientes dune socit de transport. Usager Dsigne lusager dune socit de transport, il possde une carte de transport valide. Employ Reprsente tout employ de la socit de transport. Contrat Concerne lintgralit des contrats effectus entre un usager et la socit de transport. Type_Contrat Reprsente les diffrents types de contrats existants. Type_Produit Contient les informations relatives un type de produit. Par exemple un ticket unitaire est consommable alors quun abonnement est non-consommable. Carte Reprsente la carte puce de lusager Support_Produit Cotient les produits possds par lusager sur carte. Historisation Permet de garder une trace de toutes les transactions ou modifications ayant eu lieu. Il peut retenir tous les types dinformations, aussi bien les changements de nom dun client que les validations effectues par une carte.

Analyse de la coopration

Cette phase utilise les patrons et les composants danalyse de la coopration dfinis dans le cadre des livrables 3.2 et 3.3.

17

Partie C Phases darchitecture applicative, darchitecture technique et darchitecture cooprative

Cette partie prsente les rgles de bonne pratique prconises par UP-TRAFIC pour construire une architecture applicative et technique base de composants. Ces rgles de bonne pratique sont pour la plupart proposes par la mthode Symphony, mais certains des composants techniques utiliss sont spcifiques des systmes dinformation transport, et donc introduits explicitement dans UP-TRAFIC : il sagit des composants daccs progressif linformation et dinterrogation visuelle.

Architecture applicative

Lobjectif de larchitecture applicative est de spcifier les composants techniques mettre en place pour supporter lexcution des composants mtier. Cette phase est ralise en parallle avec les exigences fonctionnelles. Elle permet danticiper les dveloppements des composants gnriques (ne contenant aucun savoir mtier). Elle reprsente la spcification des composants techniques et de leur collaboration les uns avec les autres. Les activits de cette phase sont les suivantes : dcrire les diffrentes couches applicatives, recenser et cartographier les composants techniques, dcrire les composants et classes techniques, dfinir les rgles de conception et de transformation.

1.1

Description des couches applicatives

La spcification de ces couches consiste appliquer des patrons de conception (tels que Faade, Layers par exemple) pour spcifier lensemble des couches applicatives de larchitecture logicielle. Une architecture multi-couches permet alors de rpondre des objectifs qualitatifs permettant datteindre de hauts niveaux de productivit, de maintenance et de rutilisation grce la dcomposition du systme en sous systmes. La relation de dpendance entre les diffrentes couches signifie quun composant de la couche infrieure ne peut pas accder un composant de la couche suprieure : on parle de dcouplage. Cette notion correspond au patron de conception Layers et permet : dattribuer aux quipes de ralisation des responsabilits sur le dveloppement de chaque couche, de masquer les dtails dimplantation dune couche, ce qui permet de ne pas tre affect par son volution venir. Chaque couche peut tre modlise, dveloppe et teste individuellement. Cette architecture spare la logique de prsentation, la logique applicative, la logique transactionnelle et de persistance (mise jour des bases de donnes). Cette architecture multi-couches est aussi celle mise en uvre dans la socit ACTOLL. Cest pourquoi, dans le cadre de la dmarche UP-TRAFIC destine aux SIT, nous prconisons dutiliser une architecture multi-couches telle que celle prsente dans la Figure 9 qui peut 18

donc tre mise en place dans de nombreux projets de dveloppement de systmes dinformation transport.

Figure 9 : architecture multi-couches prconise par UP-TRAFIC

Les couches sont dtailles de la manire suivante : La couche Client est relative aux composants (navigateur Internet par exemple) permettant aux utilisateurs dutiliser lapplication. La couche Prsentation sassure de la dfinition des composants permettant de grer la prsentation et linteraction avec les couches infrieures. La couche Entreprise reprsente lensemble des objets mtier Entits et Donnes. Cette couche reprsente les entits qui seront persistantes, donc projetes dans la base de donnes. La couche Projection (mapping) Objet-Relationnel permet de transformer les objets mtier Entit et Donnes de rfrence en requtes SQL. Cette couche peut tre prise en charge par un framework (open source, commercial ou maison ). La couche Donnes est gnralement relative au SGBDr et aux diffrentes bases de donnes dans lesquelles sont srialiss les objets mtier de la couche Entreprise (via la couche Projection Objet-Relationnel).

1.2

Etablissement de la cartographie des composants techniques

Une fois le cadre architectural pos, lobjectif est de dfinir la cartographie des composants techniques. Il sagit en particulier de choisir des composants techniques et de dcrire leurs interactions. Cette activit constitue le cur de la phase darchitecture applicative car il faut dfinir les technologies mettre en place en convergence avec les besoins fonctionnels. Dans le cadre des applications n-tiers, Symphony recense plusieurs catgories de composants ncessaires pour le bon fonctionnement et la maintenance de ces applications. Les catgories prsentes ci-dessous sont souvent prsentes dans les applications de gestion : composants ou frameworks de prsentation (Struts, JSF par exemple), composants de projection objet relationnel (LiDO, TopLink, par exemple), composants dauthentification (JAAS par exemple), composants de notification (JavaMaiL, NetSize, par exemple), composants ddition (FOP par exemple), composants de recherche (Lucne par exemple), composants de gestion des pools de connexions.

19

Dans le cadre des applications systmes dinformation transport, UP-TRAFIC recense deux catgories supplmentaires de composants utiles pour le dveloppement dun systme dinformation transport : composants dinterrogation visuelle (langage LVIS par exemple, dvelopp dans le cadre du lot 4), composants daccs progressif linformation (dvelopp dans le cadre du lot 4). Cette cartographie est souvent dcrite par des schmas spcifiques du fait dun manque dans la notation des diagrammes de composants dUML. La Erreur ! Source du renvoi introuvable. illustre un exemple de cartographie.

1.3

Description des composants et des classes techniques

Lactivit suivante consiste dtailler ces composants techniques, leurs interfaces en particulier, les classes spcialisables, si ncessaire leur fonctionnement interne notamment pour les frameworks techniques. En effet, certains composants ncessitent un enrobage pour faciliter leur utilisation dans le cadre des dveloppements. Par exemple, lutilisation du composant FOP pour les ditions ncessite la dfinition de faades pour faciliter lappel de la commande ddition (comprenant par exemple la recherche automatique de la feuille de style, les facilits de gnration du XML, ). La conception de ces classes denrobage se fera dans la phase de conception. Nous retrouvons des situations similaires pour lutilisation des composants daccs aux bases de donnes (accs une connexion, excution dune requte, ). Mme lutilisation dun outil de projection ncessite un enrobage certes trs simple, mais utile pour viter la redondance de code. Dans la ralisation de larchitecture applicative, larchitecte applicatif doit galement dfinir le cadre dutilisation du composant (dorigine ou spcialis) dans lapplication. Cette description peut se faire par des exemples concrets dutilisation. Dans le cas dun composant complexe (ou framework technique), une documentation doit tre annexe au dossier darchitecture applicative.

1.4

Dfinition des rgles de conception et de transformation

Une des dernires activits de la phase darchitecture applicative dans le cycle en Y consiste spcifier et / ou identifier les rgles de conception et de transformation applicables dans la conception de lapplication telles que : la transformation du modle danalyse en modle de conception, la gnration des interfaces des composants distribus, la gnration des classes de composants (inutile si la gnration est ralise par un outil), la gnration du schma relationnel, la traduction des modles dtats. Cette activit permet galement de spcifier les patrons utiliser (gnraux et spcifiques la plate-forme) notamment dans les phases de conception et darchitecture technique (dcrite ciaprs).

Architecture technique

Dans la continuit de la phase prcdente, l'objectif de la phase d'architecture technique consiste dcrire l'environnement de production, l'architecture rseau et matrielle. Cette phase sert galement spcifier les contraintes d'exploitation. 20

Cette phase comprend une seule activit : la dfinition de larchitecture technique. Dans le dtail, cette activit consiste : Dcrire l'architecture existante et les contraintes d'utilisation et d'exploitation. Dfinir l'architecture technique de production rpondant aux besoins suivants : 1. dfinir les noeuds de l'architecture distribue, 2. dfinir la nature et la cardinalit des connexions des noeuds (spcification des protocoles de communication, exemple : FTP, http, SOAP, etc.), 3. associer les logiciels et les packages techniques aux noeuds. Positionner les serveurs d'applications, serveurs Web, moteurs de base de donnes sur les noeuds. Dfinir les autres environnements (de recette, d'intgration, etc.). Dfinir l'environnement de dveloppement. Dfinir les rgles d'exploitation. Dfinir la politique d'archivage. Dfinir la politique de supervision. Dfinir la volumtrie des donnes. Dfinir les batchs d'alimentation (ordonnancement). A titre dexemple, la Figure 10 illustre larchitecture technique existante dun portail Intranet dapplications hospitalire sous la forme dun diagramme de dploiement UML.

Figure 10 : architecture technique, exemple d'architecture existante

Ce diagramme montre la collaboration et la rpartition des nuds dexcution matriels (poste client, serveur), les nuds dexcution logiciels (navigateur client, serveur Web, serveur de composants, serveur de base de donnes), et les composants mtier et techniques existants. Larchitecture technique cible peut tre reprsente de la mme manire en positionnant les nouveaux objets / composants techniques ncessaires et les objets mtier potentiellement. Les phases darchitecture applicative et technique aboutissent respectivement un dossier darchitecture applicative et un dossier darchitecture technique.

Architecture cooprative

Cette phase utilise les patrons techniques de coopration dfinis dans le cadre des livrables 3.2 et 3.3.

21

Partie D Phase de conception

La conception reprsente la convergence des choix technologiques raliss dans la phase darchitecture applicative et des spcifications produites dans la phase danalyse. Cette tche permet de raliser la conception technique du systme. Le modle de conception est obtenu en appliquant des rgles de conception / transformation et un ensemble de patrons de conception lis la mthodologie. Ces patrons ont t rpertoris lors de la phase darchitecture applicative. Les activits de transformation se basent galement sur les patrons de conception tels que ceux de Gamma, ceux de J2EE, ou bien ceux dfinis lors de la phase darchitecture applicative (cf. patrons de transformation dun modle objet vers un modle relationnel selon les prconisations du framework retenu). Cette section dtaille lactivit principale de la phase de conception : la conception des CM. Dautres activits existent qui ne seront pas prsentes ici car elles ne diffrent pas de la dmarche Symphony : il sagit de la conception des scnarii dtaills et de la conception de la persistance. Concevoir un CM consiste appliquer des transformations sur les diagrammes de classes du modle danalyse pour obtenir les diagrammes de classes du modle de conception. Les rgles de conception permettent de : dcomposer le contrat pour affecter, partir de la responsabilit dun CM, les oprations lmentaires aux classes du CM et placer les oprations sur toutes les classes, ajouter les types aux attributs et les mthodes daccs, de cration, de destruction et de recherche, dterminer les classes abstraites, appliquer les diffrents patrons de conception (Fabrication, Data Access Object, etc.) pour concevoir les diffrents types dOM et obtenir une meilleure conception (volution, maintenance), choisir les structures de donnes ensemblistes (collection, array, vector ), traduire les associations (en particulier les associations multi-values et les objets associatifs), dfinir la visibilit des attributs, mthodes et rles des objets, dfinir la navigabilit des associations et sassurer que les associations sont monodirectionnelles (sauf ncessit), enfin dfinir les identificateurs techniques (ex : compteur numrique). Dans le cadre du projet TRAFIC, nous avons identifi des rgles de conception dans deux technologies : dune part vers le langage Java, un langage orient objet trs bien adapt pour implmenter des composants, dautre part vers le gnrateur de la socit ACTOLL.

Transformation vers le langage Java

Chaque composant mtier doit tre implment dans un package compos de plusieurs classes. Nous prsentons dans la suite lexemple du package Client, les packages tant tous construits de manire quasi similaire. LInterface.

22

Linterface sert communiquer avec le package en cours, elle va dfinir lensemble des mthodes et des fonctions dfinies pour la classe dimplmentation (Impl). Linterface peut tre utilise par : - la classe Factory. - dautres composants via lutilisation de leur classe rle . La classe dImplmentation Cette classe implmente la classe Interface. De plus, elle possde en attribut un objet du type Value pour le package correspondant ainsi quun objet de type DAO. Cest donc la seule classe pouvoir appeler la classe DAO, afin de modifier ou de lire la base de donnes. La classe Factory Cest une classe unique qui ne sert qu crer des objets de type Impl pour le package en cours. La plupart du temps, elle peut le crer de deux manires diffrentes : - En chargeant lobjet partir de la base de donnes laide de son identifiant (cl primaire). - En crant un nouvel objet partir de tous les paramtres ncessaires celui-ci (par exemple, pour le Client, il faudra identifiant, nom, prnom, date de naissance et lieu de naissance. La classe DAO Cette classe est la passerelle entre la base de donnes et le package. Pour accder la base de donnes, nous utilisons des ODBC (Open DataBase Connectivity), les ODBC tant une sorte de JDBC (Java DataBase Connectivity) utiliss pour relier les bases de donnes. Une classe DAO comprend toujours trois procdures et une fonction : - Store pour ajouter un nouvel lment, il prend en paramtre un objet de type Impl du package en cours. - Delete pour supprimer un lment partir de son identifiant. Lidentifiant tant gnralement lID ou le Nom. - Update pour mettre jour les valeurs dun lment. - Load qui, partir de lidentifiant, renvoie un objet de type Impl du package en cours. La classe Value Cette classe contient les attributs du composant. Ainsi, pour le client, on retrouvera son ID, nom, prnom, date de naissance, lieu de naissance... Bien entendu, elle pourra possder des procdures et fonctions. Les classes parties Chaque objet matre peut contenir des objets parties . Ces objets sont des supplments la classe Value. Par exemple, la classe ClientValue peut contenir plusieurs objets de type Statut ou Titre. Les classes rles Les classes rles sont similaires aux classes partie, la diffrence prs quelles communiquent avec une interface dun autre package. Exemple : Dans le package Client, une classe rle est HistorisationClient. Elle sert sauvegarder les changements chaque fois quun nouvel attribut est donn au client. Ainsi, pour tout ce qui concerne les changements de nom, prnom, dadresse et dajout et de suppression, on passera par la classe HistorisationClient qui, via linterface du package Historisation, sauvegardera les changements.

23

Le composant mtier Client issu de la phase danalyse est donc progressivement transform dans le package suivant :

La classe rle HistorisationClient communique avec le package Historisation et la classe rle Titre communique avec le package Contrat. Cette transformation devra sappliquer sur le diagramme de classes de chaque CM (de type Entit et Donne de rfrence). Dautres rgles de transformation pour une architecture applicative mettant en uvre des composants EJB (Entreprise JavaBeans) sont donnes dans a mthode Symphony, mais nont pas t utilises pour le projet TRAFIC et ne sont donc pas prsentes dans le cadre de la dmarche UP-TRAFIC.

24

Intgration avec le gnrateur de la socit ACTOLL

Dans le cadre de lapplication de la dmarche UP-TRAFIC au sein de la socit ACTOLL, nous pouvons reconsidrer le gnrateur et sa dmarche comme des outils dautomatisation intervenant au cours de la phase commune du cycle de vie en Y, partir de la phase de conception. Lintgration de la dmarche du gnrateur (voir livrable 2.3) UP-TRAFIC implique quelques modifications au niveau des premires phases de cette dmarche actuellement utilise par ACTOLL. En effet, la branche gauche du cycle de vie en Y engendre un modle mtier du domaine plus complet quun simple modle conceptuel de donnes (MCD). De plus, mme si ce modle peut avoir t ralis en partie par rutilisation, il est dj spcifique lapplication en cours de dveloppement. Ainsi, la partie gnrateur de la dmarche UP-TRAFIC/ACTOLL dbute par lextraction des modles physiques et du fichier XML partir du modle mtier. En effet UP-TRAFIC propose dj un patron pour transformer le modle mtier en modle de conception. Pour assembler les deux dmarches nous proposons deux patrons permettant de dfinir le modle physique partir du modle de conception (par strotypage) et un patron de transformation de ce modle tiquet en modle physique directement utilisable dans le fichier XML ncessaire au gnrateur (non prsent ici).

Nom Contexte Problme

Dfinition du modle physique Ce patron requiert un modle de conception de lapplication Ce patron permet de dfinir le modle physique en appliquant des strotypes sur un modle de conception de lapplication. 1. Dterminer, pour chaque classe, le besoin de persistance et lui appliquer le strotype <<Table>> Les classes Value est Partie issues de la modlisation mtier sont concernes, Les classes Rle galement.

Solution Dmarche

2. Pour chaque classe non Rle lue, dfinir la cl primaire (bien souvent lidentifiant issu du modle mtier). Appliquer le strotype <<PK>> (primary key) a (aux) attribut(s) concern(s). Eventuellement dfinir des cls secondaires strotypes <<SK0>>, <<SK1>>, <<SKx>> avec les

Les attributs tant considrs persistants par dfaut, si un attribut nest pas persistant, le prciser avec le strotype <<NP>>. Utile pour les attributs drivs. Incompatible avec lappartenance une cl. Un attribut ne devant pas tre vide doit tre marqu par <<NNULL>>. N.b. Induit par <<PK>>. Si une classe est compose dune autre, dfinir une <<PK_p>> dans a classe composant. Elle servira de partie de la cl primaire qui sera augmente de la <<PK>> de la classe composite.

25

3. On applique aux classes Rle le strotype <<TableJoint>> Il ny a pas appliquer <<PK>> dans une <<TableJoint>>

4. Pour chaque association reliant des <<Table>> ou <<TableJoint>> Si lassociation a deux rles compltement spcifis, il faut dterminer dans quel sens la rfrence se fera. Si le rle slectionn est monovalu Sil est total, appliquer le strotype <<FK>> Sil est partiel et si on autorise les valeurs nulles appliquer le strotype <<FK>>, sinon le strotype <<NNULL>> est multivalu, appliquer le

Cas Application

Si le rle slectionn strotype <<REF>>

<<Table>> <<PK>>

<<FK>> <<Tablejoint>> <<REF>> <<REF>> <<Table>> <<PK_p>> <<Tablejoint>>

26

Partie E Conclusion
En terme de processus de dveloppement, UP-TRAFIC est, comme beaucoup de mthodes actuelles bases sur un processus unifi, une dmarche itrative incrmentale oriente utilisateur et pilote par les cas dutilisation base sur un cycle de vie en Y. Le modle en flocons gnralisant le cycle de vie en Y de UP-TRAFIC, et les phases de modlisation mtier permettent dsormais une dcomposition systmatique dun systme dinformation en autant de processus mtier que ditrations de dveloppement. Les phases de modlisation mtier (tude pralable, spcification conceptuelle et organisationnelle des besoins) sont destines faciliter lidentification des composants mtier et llaboration de la cartographie fonctionnelle du systme informatique cible. Cette identification se situe en amont du processus de dveloppement, au dbut de lexpression des besoins. Le modle conceptuel de composants mtier dcompose chaque composant mtier en trois parties : le contrat avec lextrieur (ce que je sais faire), la partie structurelle (ce que je suis), et la partie collaboratrice (ce que jutilise). Ce modle prend en compte trois types de composant mtier : Processus, Entit et Donnes de rfrence. Que ce soit au niveau de la branche fonctionnelle ou de la branche technique de son cycle de vie, la dmarche est oriente respectivement composant mtier et composant technique puisque lapplication est vue, tant au niveau conceptuel que logiciel, comme un assemblage de composants mtier et de composants techniques indpendants et interconnects. Cette orientation a pour objectif de garantir une bonne modularit des spcifications et de faciliter ainsi leur rutilisation. La dmarche prend en compte la coopration en intgrant dans chacune des phases les patrons et composants de coopration dfinis dans le cadre du lot 3. Enfin, compte tenu des contraintes dexploitation du systme cible, les phases darchitecture applicative et technique contribuent mettre en uvre une architecture base de composants techniques rpartis sur un modle darchitecture multi-couches. Ds la phase darchitecture applicative, UP-TRAFIC met laccent sur lapplication de patrons darchitecture et de conception pour spcifier lensemble des couches applicatives. De plus, la dmarche UP-TRAFIC recommande fortement lutilisation de deux types de composants techniques raliss dans le cadre de ce projet : un composant technique langage visuel dinterrogation (utile par exemple pour interroger de faon visuelle les horaires de transport, etc.), et un composant technique daccs progressif linformation. Cette phase se proccupe galement de dfinir les rgles de conception et de transformation applicables lors de la phase de conception. Dans le cadre du projet TRAFIC, dune part des rgles de transformation ont t dfinis vers le langage orient objet Java, dautre part, un patron a t dfini permettant dintroduire dans le gnrateur de la socit ACTOLL les composants mtiers issus de la phase danalyse. Ainsi, la dmarche couvre un cycle complet de dveloppement de systmes dinformation transport, partant de la spcification des processus mtiers, et allant jusqu limplantation de ces processus mtiers dans des technologies classiques de dveloppement de systmes dinformation (par exemple le langage orient objet Java) ou dans des technologies spcifiques aux SIT (par exemple le gnrateur mis en uvre dans la socit ACTOLL). La formalisation sous forme de patrons de ces rgles ainsi que la description des composants techniques peuvent augmenter de manire consquente la capacit maximiser la rutilisation de ces composants.

27