Conception de l architecture d un système dirigée par un modèle d urbanisme fonctionnel

Transcription

1 Concepton de l archtecture d un système drgée par un modèle d urbansme fonctonnel Jacques Smonn To cte ths verson: Jacques Smonn. Concepton de l archtecture d un système drgée par un modèle d urbansme fonctonnel. Software Engneerng [cs.se]. Unversté Rennes, French. <tel > HAL Id: tel Submtted on 27 Aug 200 HAL s a mult-dscplnary open access archve for the depost and dssemnaton of scentfc research documents, whether they are publshed or not. The documents may come from teachng and research nsttutons n France or abroad, or from publc or prvate research centers. L archve ouverte plurdscplnare HAL, est destnée au dépôt et à la dffuson de documents scentfques de nveau recherche, publés ou non, émanant des établssements d ensegnement et de recherche franças ou étrangers, des laboratores publcs ou prvés.

2 N ORDRE : 3844 de la thèse THÈSE présentée DEVANT L'UNIVERSITE DE RENNES pour obtenr le grade de DOCTEUR DE L UNIVERSITE DE RENNES Menton : INFORMATIQUE par Jacques SIMONIN Équpe d accuel : Trskell IRISA École doctorale : Matsse Composante unverstare : IFSIC TITRE DE LA THÈSE : Concepton de l'archtecture d'un système drgée par un modèle d'urbansme fonctonnel Soutenue le 29 janver 2009 devant la commsson d examen COMPOSITION DU JURY : Rapporteurs : Colette ROLLAND Alan WEGMANN Examnateurs : Danel HERMAN Présdent du jury Yves LE TRAON Francs ALIZON Jean-Marc JEZEQUEL Drecteur de thèse

3

4 Remercements Je remerce Colette Rolland et Alan Wegmann pour l'ntérêt accordé à ma thèse. Leurs remarques constructves me seront très utles pour la sute de mes travaux. Je remerce Danel Herman qu m'a fat l'honneur de présder le jury. Je remerce Jean-Marc Jézéquel d'avor drgé ma thèse et de m'avor fourn une ade préceuse quant à la "transformaton" d'un dscours d'ngéneur en un dscours académque. J'assoce à ce remercement Yves Le Traon pour m'avor toujours encouragé et pour m'avor fourn des pstes de recherche que j'a été très heureux de suvre. Je remerce Francs Alzon avec qu j'a partagé mes premères dées sur l'urbansme et le développement de système. Je le remerce également pour sa grande qualté d'écoute tout au long de cette thèse. Je remerce la Drecton de la Recherche de FT R&D, et plus partculèrement la commsson "Thèses et HDR pour IG R&D", de m'avor fat confance dans le cadre de mon projet de thèse. Je remerce Fouz Menaï et Jean-Perre Deschrevel de FT R&D qu ont perms à ces travaux de démarrer grâce à des problèmes d'archtecture ben conçus et à des réflexons pertnentes. Je remerce Potr Kołodzejsk, Leszek Kozłowsk, Rafał Malczewsk, Janusz Kowalczyk et Marek Dabrowsk de TP R&D, Katell Henry, Grégore Dupé, Jaml Chawk et Benot Hellequn de FT R&D pour leur partcpaton au prototypage des démarches. Je remerce Olver Boëffard de l'enssat et Emmanuel Bertn de FT R&D pour les échanges enrchssants que j'a pu avor avec eux sur certans aspects de mes travaux. Je remerce toutes les personnes de l'équpe projet drgée par Hervé Le Corre et par Alexs Bafcop, ans que les personnes de l'unté de recherche et de développement de FT R&D drgée par Bertrand Ncolas, pour toutes nos nteractons sur l'urbansme des servces télécom. Je remerce plus partculèrement Sébasten Povre qu a enduré un peu plus que les autres l'avancement de ma réflexon. Pour la même rason, je remerce Goulven Furet, mon vosn de bureau, qu a supporté avec bonne humeur mes nterrogatons en temps réel autour de cette thèse. J'assoce à ces remercements tous les membres de l'équpe Trskell de l'irisa que j'a pu croser à l'occason de cette thèse, en partculer, Loïc Lesage pour son effcacté lors de l'organsaton de mes dfférentes venues à Rennes. Je voudras enfn remercer Sophe qu m'a accompagné durant ce projet de thèse et qu m'accompagne dans la ve. Elle s'est ntéressée à ce domane de l'archtecture, nouveau pour elle, et elle m'a perms de travaller dans les melleures condtons possbles. A Sophe, ma femme, et à Maron, ma flle. 3

5

6 Résumé Résumé La durablté d'un système d'nformaton (SI) peut être caractérsée en bonne parte par la réutlsablté de ses servces lors de la réalsaton des processus méter de l'entreprse. L'archtecture orentée servces (SOA) pour un SI nécesste la prse en compte de la stratége d'entreprse (marketng et évolutons technologques) dans la concepton des servces afn d'augmenter la réutlsablté de servces exstants. C'est l'objectf de l'archtecture d'entreprse (EA), ou de l'urbansme, qu défnt une cble archtecturale offrant une durablté optmum du SI. Afn d'amélorer la réutlsaton de servces lors de l'évoluton d'un SI, nous proposons d'ntégrer une approche dynamque fondée sur l'ea pour toute nouvelle réalsaton d'un processus méter de l'entreprse. Le prncpe de cette approche dynamque est de prendre en compte, lors de chaque usage de servces, d'une part, les fonctons et les données manpulées et, d'autre part, les solutons technques. L'améloraton de la durablté du SI est évaluée dans notre approche par une mesure d'algnement entre l'archtecture des servces développés dans le SI et l'ea fonctonnelle de ce SI. Mots Clés : Système d'informaton, durablté d'un Système d'informaton, archtecture d'entreprse, urbansme, archtecture orentée servce, ngénere des modèles, ngénere / archtecture drgée par les modèles, algnement de modèles, mesure d'algnement. Abstract The sustanablty of an Informaton System (IS) can be manly characterzed by the servces reusablty durng the mplementaton of the company busness processes. The Servce Orented Archtecture (SOA) deployed n an IS requres to take nto account the company strategy (marketng and technologcal evolutons) durng the servce desgn. The am s the exstng servces reusablty mprovement. Ths s the purpose of ether the Enterprse Archtecture (EA), or the urbansm, to defne an archtectural target provdng an IS optmal sustanablty. In order to mprove the servce re-use durng an IS development, we suggest to ntegrate a dynamc approach based on EA for any new mplementatons of a company busness process. The dynamc approach prncple conssts durng every servces use, on one hand, the functons and the manpulated data and on the other hand, the techncal solutons. The IS sustanablty mprovement s estmated n our approach by an algnment measure between the IS servces archtecture and the functonal EA of ths IS. Keywords: Informaton System, sustanable Informaton System, Enterprse Archtecture, urbansm, Servce Orented Archtecture, model engneerng, Model Drven Engneerng / Archtecture, model algnment, algnment measure. 5

7

8 Table des Matères Remercements... 3 Résumé... 5 Table des Matères Introducton Contexte Contrbuton....3 Plan du document État de l'art Archtecture d'entreprse Durablté d'un SI et réutlsablté Généraltés sur l'ea Dfférents cadres de l'ea Un cadre partculer de l'ea : l'urbansme EA et modélsaton Vues d'archtecture Méta-modélsaton et vues assocées au cadre de l'urbansme Algnement entre la vue méter d'une entreprse et les vues du SI Développement d'un système Processus de développement UP Aspect dynamque d'un système Développement d'un système et approche MDA Concluson La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Prncpes La vue fonctonnelle dédute de la vue méter ou algnée avec la vue méter? Descrpton d'ensemble de la démarche DA4EA Concepton experte des zones et des îlots du PLU fonctonnel Concepton des îlots du PLU fonctonnel Défnton du typage d'un îlot fonctonnel Transformaton des îlots du PLU fonctonnel contrante par le typage Transformaton des voes du PLU fonctonnel contrante par le typage des îlots Algnement de la vue méter d'une entreprse et de la vue fonctonnelle d'un SI Défnton de l'algnement de la vue fonctonnelle avec la vue méter Axomatsaton de l'algnement de la vue fonctonnelle avec la vue méter Mesure de l'algnement de la vue fonctonnelle avec la vue méter Concepton automatsée des quarters du PLU fonctonnel Approche dynamque de la concepton des quarters Pertnence d'un regroupement d'îlots fonctonnels dans une même entté fonctonnelle Seul d'nserton d'un îlot fonctonnel dans une entté fonctonnelle Algorthme bactérologque de concepton des quarters fonctonnels à partr des enttés fonctonnelles Expérmentaton avec le SI supportant le processus méter d'usage d'un servce télécom Démarche applquée à la zone Messagere Évaluaton de la démarche DA4EA Contexte du prototypage de la démarche DA4EA Blan du prototypage de la démarche DA4EA Analyse du blan du prototypage de la démarche DA4EA

9 3.7.4 Blan comparatf avec la zone Messagere exstante Concluson La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Prncpes Pourquo l'urbansme fonctonnel? Pourquo une approche dynamque? Démarche EA4UP et ngénere des modèles Descrpton d'ensemble de la démarche EA4UP Démarche EA4UP fondée sur l'approche dynamque et l'ngénere des modèles Collecte des exgences Analyse Concepton de l'archtecture fonctonnelle Concepton de l'archtecture technque Concepton de l'archtecture applcatve Implémentaton Test Évaluaton de la démarche EA4UP Contexte du prototypage de la démarche EA4UP Blan du prototypage de la démarche EA4UP Analyse du blan du prototypage de la démarche EA4UP Concluson Démarche EA4UP et SOA Blan de la démarche EA4UP Démarche EA4UP et mesure d'algnement fonctonnel de type nformaton mutuelle moyenne Prncpes Défnton de l'algnement fonctonnel Axomatsaton de l'algnement fonctonnel Chox d'une mesure de l'algnement fonctonnel Démarche EA4UP et théore de l'nformaton Analyse fonctonnelle dynamque et transmsson d'nformaton PLU fonctonnel et contrante de transmsson Algnement fonctonnel et système de communcaton Défnton du système de communcaton Codage d'nformaton et approche MDA Décodage d'nformaton et approche MDA PLU fonctonnel et canal de communcaton Canal de communcaton et approche MDE Nveaux du PLU et lo de transton Mesure d'algnement fonctonnel et nformaton mutuelle moyenne Chox de l'nformaton mutuelle moyenne Formule de l'nformaton mutuelle moyenne pour l'algnement fonctonnel Concluson Concluson Perspectves Références bblographques Lste des publcatons personnelles et des brevets Acronymes Table des règles d'urbansme Table des Fgures Table des Tableaux

10 Introducton. Introducton. Contexte La réusste du management d'une entreprse repose classquement sur cnq ponts prncpaux : fxer des objectfs, organser le traval, motver et communquer, mesurer la performance, former les salarés [Drucker, 983]. La fxaton des objectfs sous-entend une stratége de l'entreprse dont sont dérvés ces objectfs. La stratége permet prncpalement la prse en compte de l'évoluton d'un marché. Dans le cas d'un opérateur de télécommuncatons, elle dot auss antcper les ruptures technologques. L'entreprse dot donc s'adapter à l'évoluton de son envronnement et à l'évoluton de sa propre stratége. Il est mportant de soulgner l'accélératon actuelle de la stratége de crossance des entreprses. Cette stratége de crossance est matéralsée par une créaton de moyens de producton ou de fnancement nouveaux, par une fuson avec d'autres entreprses, etc. L'organsaton de l'entreprse dot répondre à sa stratége. Parm les facteurs de réusste ctés par Peter Drucker, le traval organsé nécesste des standards ou normes Conséquence du taylorsme, le traval dans l'entreprse est défn méthodologquement par des modes opératores qu sont des successons de tâches. Ces modes opératores permettent d'attendre les objectfs de producton de l'entreprse. Ils nécesstent une structure organsatonnelle, c'est-à-dre des untés organsatonnelles et un réseau qu les rele. Un élément de la structure organsatonnelle contrbue alors à une ou pluseurs tâches de ces modes opératores. Cette contrbuton est en général affectée à un rôle. Par exemple, la vente d'un produt est affectée à un rôle de vendeur. Lors de la vente d'un produt, l'unté organsatonnelle du vendeur est relée avec l'unté organsatonnelle de facturaton responsable de la facturaton du produt. En plus de son organsaton qu la caractérse, l'entreprse est dentfée depus une qunzane d'année par les processus qu décrvent son cœur de méter et non plus à partr de la décomposton du traval en tâches créée par Adam Smth en 776. Il s'agt de l'approche de réngénere où le processus est défn comme une sére d'actvtés qu, ensemble, produsent une valeur pour un clent [Hammer, 993]. La descrpton d'un processus explque comment les ressources de l'entreprse (compétences, machnes, man d'œuvre) sont organsées pour produre cette valeur. La réngénere, qu est née en Amérque du Nord, permet de s'adapter à l'accélératon de l'évoluton des besons du clent, à la concurrence de plus en plus forte et au changement dans l'entreprse et en dehors de l'entreprse. Concernant les compétences et la man d'œuvre, les rôles utles à l'entreprse sont joués par ses ressources humanes. Elles permettent à l'entreprse de défnr son organsaton et ses objectfs. C'est donc à l'entreprse de fare correspondre au meux ses ressources humanes avec les rôles qu contrbuent aux processus défnssant son cœur de méter [Crozer, 994]. La responsablté de chaque rôle défne sur chaque processus permet en effet de dmensonner correctement les ressources nécessares à chaque processus. L'optmsaton du dmensonnement des processus revent à coordonner les actvtés dédées à chaque rôle de l'entreprse de manère à mnmser le coût des ressources nécessares [Burlton, 200]. 9

11 Introducton Le traval organsé nécesste auss la mse à dsposton d'nformatons sur la producton dans l'entreprse. La mse à dsposton de ces nformatons est décrte dans un Système d'informaton (SI) de l'entreprse. La stratége de l'entreprse a des conséquences sur le SI. L'accélératon de la stratége de crossance de l'entreprse, l'évoluton de son organsaton et des processus auxquels elle contrbue sont source de complexté pour l'entreprse [Morn, 990]. Cette complexté nécesste des modèles de compréhenson et des modèles d'nterventon. Les modèles représentent les nteractons des éléments de l'entreprse nécessares à la producton. La complexté d'un Système d'informaton est par exemple lée aux nteractons des systèmes qu le consttuent. Le système est une unté complexe dépendante de son objet, mas auss de son organsaton et de ses assocatons avec son envronnement. Par analoge avec les types de modèles proposés par Edgar Morn, l'objectf de l'archtecture d'entreprse (EA : Enterprse Archtecture) d'un SI [Zachman, 987] serat de proposer : - un modèle de compréhenson en décrvant l'exstant du SI, par exemple un système de commande en agence commercale, un système de commande par l'ntermédare d'un portal, un système de facturaton et le len exstant entre eux, - un modèle d'nterventon en défnssant une cble pour le SI, par exemple un nouveau système de commande unfée et son len avec le système de facturaton exstant. Cette descrpton de l'exstant, ou cartographe, a une autre utlté lorsqu'elle cble les processus méter de l'entreprse. La cartographe permet en effet de reconfgurer les processus et donc de permettre une durablté des grandes fonctons de l'entreprse (foncton stratégque, foncton opératonnelle, foncton logstque). La durablté de ces fonctons est défne par l'apttude de l'entreprse à évoluer au gré des transformatons du marché, de l'évoluton des technologes ou des fusons d'entreprse. Les technologes de l'nformaton sont un catalyseur mportant de cette durablté. Il est ntéressant de noter que la mse en œuvre de ces technologes de l'nformaton dans la réngénere est de nature nductve et non déductve [Hammer, 993]. Cec sgnfe que la détecton d'une soluton permet de résoudre des problèmes postéreurs à la soluton. C'est un fondement de l'ea au travers de la défnton d'un SI cble. L'objectf de l'ea est en effet, à partr d'une cartographe du SI de l'entreprse, de défnr un SI cble permettant de supporter les évolutons du marché avant que ces évolutons ne soent défnes de façon détallée. La stratége prse en compte en entrée de la défnton du SI cble a pour objet de décrre de façon macroscopque certanes de ces évolutons. C'est donc à partr de cette stratége de l'entreprse que la cble de l'ea est défne. La complexté des systèmes ndut des comportements nattendus. L'EA dot favorser la matrse des comportements nattendus des systèmes d'un même SI d'une entreprse. C'est par exemple le cas lorsqu'une même donnée décrvant le clent d'une entreprse est modfée dans des systèmes dfférents de façon non coordonnée. L'objectf de l'ea est alors de dmnuer les comportements ncertans en proposant un modèle archtectural de référence du SI. Dans l'exemple proposé, un des systèmes sera responsable de la mse à jour de la donnée décrvant un clent et l'autre système nteragra avec lu pour récupérer la donnée. Cette dmnuton nécesste d'axer l'ea sur la stablté dynamque du SI et des systèmes de ce SI. Les comportements dynamques d'un SI, d'un système ou de l'entreprse avec sa structure organsatonnelle sont analogues. Dans ces tros cas llustrant l'approche systémque, l s'agt d'ensemble d'untés et d'nteractons entre ces untés [Rosnay, 975]. L'approche systémque englobe les éléments du système au sens large ans que leurs nteractons. La vson dynamque ntègre le temps afn de soulgner le comportement du système selon des scénaros d'usage du système. L'objectf de stablté dynamque permet l'évolutvté du système et sa durablté. 0

12 Introducton Les tâches des modes opératores de l'entreprse sont automatsées ou non dans son SI. L'algnement du SI sur l'organsaton de l'entreprse devent un ndcateur pertnent de la durablté du SI par rapport à celle de l'entreprse. La durablté de l'entreprse est mse en valeur par l'ntégraton de sa stratége dans les processus de l'entreprse qu'elle utlse pour produre de la valeur. Un SI durable est ms en valeur par l'ntégraton de cette stratége dans les systèmes du SI de l'entreprse qu'elle utlse pour produre de la valeur. Un des ndcateurs de la durablté du SI est l'algnement de chaque système du SI avec l'ea représentant les mpacts de la stratége sur le SI. Dans l'exemple du SI cble comportant un système de commande et un système de facturaton, la créaton d'un système de commande spécfque à un type de produt tel qu'un téléphone du réseau moble pour un opérateur de télécommuncatons est source de désalgnement avec le SI cble. L'ntégraton de la commande du téléphone du réseau moble au système de commande unfé aurat par contre ndut un algnement parfat avec le SI cble..2 Contrbuton Comme l'ndque Edgar Morn dans [Morn, 990], "Le refus de la complexté génère le désordre et la confuson". La complexté due à l'évoluton de l'entreprse rend nécessare la durablté de son SI. La contrbuton de cette thèse est défne comme une offre d'assstance aux archtectes dans leur volonté de dmnuer le désordre et la confuson lors de la concepton d'un système ou d'un SI : - Assster la modélsaton de l'ea fonctonnelle d'un SI, c'est-à-dre la modélsaton fonctonnelle du SI, en s'appuyant sur une vue dynamque de ce SI. L'objectf serat, par exemple, de faclter la concepton de la vue fonctonnelle d'un SI de commande à partr de scénaros fonctonnels lés à la commande tels que la créaton d'une commande d'un téléphone du réseau moble en agence, la créaton d'une commande d'un servce télécom de messagere sur un portal, etc. - Assster le développement d'un système en s'appuyant sur l'ea, sur l'ngénere des modèles afn d'ntégrer le modèle de l'ea fonctonnelle du SI et sur une vue dynamque du système. Dans l'exemple du SI de commande, l'objectf serat de faclter le développement d'un système de commande sur un portal en ntégrant l'ea fonctonnelle du SI et en étudant les dfférents usages du système par l'ntermédare des dfférents scénaros de commande sur un portal tels que la créaton d'une commande, la modfcaton d'une commande, etc. - Assster l'archtecte fonctonnel d'un système en proposant une mesure de l'algnement de son système avec l'ea fonctonnelle du SI qu s'appue sur les prncpes de la théore de l'nformaton et sur une vue dynamque du système. La réutlsaton d'éléments permettant de dmnuer les coûts, l'objectf est d'évaluer l'effort en termes de ressources pour développer ce système. Toujours dans le cadre du SI de commande et du système de commande sur un portal, l'objectf est de donner au développeur du système une ndcaton de l'écart entre le modèle fonctonnel du système de commande sur un portal qu'l a conçu et l'ea fonctonnelle du SI..3 Plan du document Sute à un état de l'art décrt dans le chaptre 2, la contrbuton de la thèse est détallée dans les tros chaptres suvants. Le chaptre 3 présente la démarche DA4EA (Dynamc Approach for Enterprse Archtecture) permettant de modélser l'ea fonctonnelle d'un SI. La démarche DA4EA est llustrée et évaluée avec la vue fonctonnelle du SI supportant le processus méter d'usage d'un servce télécom. Le chaptre 4 présente la démarche EA4UP (Enterprse Archtecture for Unfed Process) de développement d'un système du SI ans que son évaluaton. L'utlsaton de l'ngénere des modèles dans les actvtés de concepton d'archtecture d'ea4up est décrte dans ce chaptre ans que son llustraton avec un cas d'utlsaton de servce télécom. Un blan d'ea4up sute à son prototypage par des projets de développement de servces télécom complète la descrpton de la démarche.

13 Introducton Le chaptre 5 présente une mesure d'algnement entre l'archtecture d'un système du SI et l'ea fonctonnelle du SI. Les concepts d'ea4up sont rapprochés de concepts de la théore de l'nformaton. Ce rapprochement permet de présenter l'nformaton mutuelle moyenne comme mesure d'algnement. Une llustraton de ces mesures d'algnement est présentée avec quelques cas d'utlsaton de servces télécom. Une concluson et des perspectves à court, moyen et long termes de la contrbuton de la thèse sont proposées respectvement dans le chaptre 6 et dans le chaptre 7. 2

14 État de l'art 2. État de l'art 2. Archtecture d'entreprse 2.. Durablté d'un SI et réutlsablté Le Système d'informaton (SI) représente l'ensemble des ressources humanes, des ressources matérelles et des ressources logcelles nterconnectées afn de collecter, stocker, trater et communquer les nformatons. Le système nformatque est la parte du SI rédute aux ressources logcelles [Bren, 997]. Le SI coordonne les actvtés de l'organsaton de l'entreprse grâce à l'nformaton et permet ans d'attendre les objectfs de l'entreprse. L'évoluton des objectfs de l'entreprse est donc un facteur central de l'évoluton d'un SI. Un objectf de vente de produts au travers d'un portal sur Internet provoque par exemple une évoluton du SI d'une entreprse où la vente ne se fat qu'en agence de dstrbuton. Cette évoluton mplque : - des mpacts fonctonnels, s l'entreprse consdère que cette foncton de vente est dfférente d'une foncton de vente classque. Cela peut être le cas avec une noton de cadde vrtuel permettant de modfer la commande en temps réel, - des mpacts technques avec les technologes lées à l'internet, - des mpacts applcatfs avec l'extenson ou la créaton d'une nouvelle applcaton réalsant cette vente par correspondance déployée sur Internet. Le problème de la réutlsablté de l'exstant est alors de gérer au meux les évolutons de l'entreprse au travers de son SI. La réutlsablté d'éléments du SI est donc un facteur de sa durablté (cf..). L'archtecture orentée objet, l'archtecture orentée composants et l'archtecture orentée servces sont au cœur de la concepton des systèmes d'un SI [Wang, 2004]. Le servce est fondé sur pluseurs composants, par exemple un servce de commande peut s'appuyer sur un composant de geston des commandes, un composant de geston du clent et un composant de geston du catalogue. Le composant est mplémenté à partr de technologes orentées objet telles qu'uml, Java, etc. Un composant est caractérsé par le fat qu'l peut nteragr avec d'autres composants. Dans l'exemple, le composant de geston de la commande nteragt avec le composant de geston du clent afn d'dentfer le clent de la commande. La concepton à partr de composants permet la réutlsablté de composants exstants dans l'entreprse, et donc favorse la dmnuton des coûts de développement. L'archtecture orentée objet permet de modélser l'archtecture orentée composants. L'ntérêt de l'archtecture orentée servces (SOA) est de permettre l'mplémentaton d'enchaînements de tâches réalsant un processus méter. L'archtecture orentée servces fournt une méthodologe permettant d'organser et d'utlser des ressources du système nformatque de manère dstrbuée [Schulte, 996]. L'archtecture SOA peut ans favorser la réutlsaton des servces offerts dans le SI de l'entreprse lors du développement de tous nouveaux systèmes. La dffculté est néanmons de ben défnr ces servces afn de les réutlser de la manère la plus pertnente, en partculer par rapport aux fonctons que réalsent ces servces. 3

15 État de l'art La modélsaton des processus méter peut bénéfcer d'une approche orentée servces [Cauvet, 2008]. Les servces orchestrés pour représenter un processus méter peuvent être des servces méter défns à l'ade d'un vocabulare partagé dans l'entreprse et modélsant une parte d'un processus méter. Cette parte d'un processus reste spécfque aux objectfs de l'entreprse et aux ressources utles à sa réalsaton. Le len avec la stratége de l'entreprse favorse la concepton de l'archtecture du processus méter par rapport à l'enchaînement des tâches lées aux nteractons avec le clent. La réutlsaton des servces est ans facltée. La durablté d'un SI dans le cas d'une archtecture de ses systèmes orentée composants repose sur l'archtecture de la vue méter de l'entreprse et sur les modèles d'analyse de la vue fonctonnelle du SI [Fngar, 2000]. Un référentel de composants conçus à partr de ces éléments dot favorser la réutlsaton de ceux-c lors de leur assemblage dans un système. La stratége de l'entreprse reste le pont de départ du développement des systèmes car elle est la source de la spécfcaton du référentel de processus et du référentel de modèles d'analyse fonctonnels. La réutlsaton peut auss s'appuyer sur des patrons défnssant des problèmes récurrents et la soluton assocée. C'est le cas des patrons défns pour les SI produts qu recouvrent l'organsaton de l'entreprse et le système nformatque partcpant au développement d'un produt de l'entreprse [Cauvet, 2000]. L'archtecture fonctonnelle cble d'un SI peut être consdérée comme un patron fonctonnel favorsant la réutlsaton de composants applcatfs. En effet, la concepton des patrons repose sur une démarche nductve telle que recommandée pour la réngénere (cf..). De plus, l'utlsaton de modèles de composants assmlables à des patrons et favorables à la réutlsaton est préconsée pour le développement de grand systèmes [Ambler, 998]. Elle permet de smplfer les développements orentés objet de tels systèmes Généraltés sur l'ea L'évoluton des SI s'accélère du fat de l'nformatsaton grandssante des entreprses et des nouveautés technologques. La dffculté pour une entreprse est alors de condure l'évoluton du SI au leu de la subr. C'est le prncpe fondateur de l'archtecture d'entreprse ou EA (Enterprse Archtecture). L'EA offre une représentaton des connassances d'une entreprse et la manère dont elles sont supportées [Zachman, 987]. Cette représentaton recouvre : - les descrptons de l'organsaton de l'entreprse et de ses objectfs, - les dfférentes modélsatons de ses processus méter, de son SI et de son système nformatque. L'EA offre pluseurs ponts de vue du SI. Ces ponts de vue sont auss ben celu des décdeurs axé sur la stratége de l'entreprse, que celu des développeurs comprenant l'archtecture des systèmes du SI. Pour ce pont de vue de l'archtecture des systèmes du SI, l'objectf est de résoudre les exgences fonctonnelles ou non fonctonnelles parfos contradctores dans un SI et d'optmser les échanges entre ces systèmes. C'est la problématque des très gros systèmes (ULS system : Ultra-Large-Scale system) applquée à un SI consdéré comme un système de systèmes et à ses règles de concepton [Baldwn, 2000]. La soluton proposée par l'ea est de découper ce pont de vue des systèmes en vues, ou vsons, complémentares telles qu'une vue méter ou une vue technque du SI. Ces vues devennent la référence pour tous les systèmes du SI. 4

16 État de l'art L'EA est fondée de façon macroscopque sur quatre processus [Urba-EA, 2006] : - la descrpton des ressources de l'entreprse (humanes ou logcelles) nteragssant avec le SI de l'entreprse. Cette descrpton de ressources, ou cartographe, permet de gérer l'évoluton du SI en répertorant l'exstant. Parm les ressources logcelles, la donnée est au cœur du système d'nformaton. Elle représente l'nformaton tratée par le SI. Après le recensement des applcatons, un des premers objectfs de la cartographe est de défnr les données référentelles de chaque applcaton. L'objectf est de défnr l'applcaton responsable de chaque donnée du SI [Urba-SI, 2003] ; - la défnton d'une EA cble par rapport aux axes stratégques de l'entreprse. Lorsque cette cble est attente, le SI est dt durable. Les éléments du SI étant en phase avec la stratége de l'entreprse, ls ont en effet une durée de ve plus longue et devennent réutlsables pour de nouveaux développements de systèmes ; - la mgraton du SI exstant vers un SI conforme à l'ea cble. Cette mgraton est en général spécfée dans un schéma drecteur de l'entreprse qu donne une vson stratégque de cette entreprse à 3 ou 4 ans ; - la mse en œuvre de la cble par les projets de développement de système. Il s'agt pour ces projets d'ntégrer l'ea cble lors de la concepton de l'archtecture d'un système. Les rôles contrbuant à ces processus sont : - la maîtrse d'ouvrage (MOA) du projet d'ea, sot le clent du projet de concepton de l'ea, - la MOA du projet de développement d'un système, sot le clent de ce projet, - l'archtecte d'entreprse qu conçot les dfférents ponts de vue de l'ea, - le cartographe du SI qu cartographe les systèmes exstants du SI, - l'archtecte du système à développer dans le SI. 5

17 État de l'art Les contrbutons de chaque rôle dans les quatre processus lés à l'ea sont représentées dans le dagramme d'actvtés UML (cf. 2..5) de la Fgure. Fgure : Processus lés à l'ea et rôles contrbuteurs Les évènements déclencheurs des ces processus lé à l'ea sont défns de la façon suvante : - le lancement d'un projet d'ea qu répond à la défnton par l'entreprse d'une stratége, - le lancement d'un projet de système qu répond à la défnton du beson d'un utlsateur de ce système. 6

18 État de l'art La durablté d'un SI est favorsée par les apports de l'ea applquée à un SI : - la dmnuton des coûts de développement et de mantenance due à la réutlsaton d'éléments du SI satsfasant les préconsatons de l'ea, - la facltaton de la mgraton technque d'un SI (changement d'os, etc.) ou de la mgraton fonctonnelle d'un SI (passage d'un clent du marché entreprse ou du marché grand publc à un clent du réseau fxe ou du réseau moble pour un opérateur de télécommuncaton, etc.) à partr de la cartographe complète du SI exstant et de la défnton de l'ea cble, - l'homogénété des solutons technologques utlsées et leur cohérence avec les exgences technques spécfques à l'entreprse (nombre de clent, talle et confguraton du réseau de l'entreprse, etc.), - l'assstance effcace à la fuson d'entreprse à partr du partage du pont de vue méter des entreprses fusonnées Dfférents cadres de l'ea Pour amélorer la durablté du SI, les archtectes d'entreprse dsposent de dfférents cadres. Ces cadres défnssent une EA reposant sur dfférents ponts de vue de l'entreprse (pont de vue méter, pont de vue organsatonnel, pont de vue des systèmes, pont de vue technque, etc.). Ces ponts de vue permettent d'évaluer les mpacts des dfférents axes stratégques défns par l'entreprse. La plupart de ces cadres sont dérvés du cadre de référence de Zachman représenté dans la Fgure 2 [Zachman, 987]. Fgure 2 : Cadre de référence de Zachman 7

19 État de l'art Les cadres de l'ea sont très, vore trop, nombreux [Schekkerman, 2006]. Certans d'entre eux sont devenus des références pour l'ea : - le TOGAF (The Open Group Archtecture Framework [TOGAF, web], - le DoDAF (Department of Defense Archtecture Framework) [DoDAF, web] et ses dervés de l'otan ou du Royaume Un, - l'itil (Informaton Technology Infrastructure Lbrary) [ITIL, web], - le RM-ODP (Reference Model for Open Dstrbuted Processng) [RM-ODP, web]. Le TOGAF, créé par un consortum ndustrel (Open Group fondé par IBM, Sun Mcrosystems, Htach, Hewlett-Packard, Fujtsu), propose une méthode ADM (Archtecture Development Method) et un ensemble d'outls de concepton de l'archtecture d'entreprse en complément d'un envronnement d'archtecture. La méthode ADM de concepton de l'ea est fondée sur la geston des exgences au nveau de l'entreprse. Ces exgences sont dédutes des objectfs et des orentatons méter de l'entreprse. L'archtecture de chaque pont de vue conçue à partr de ces exgences cble le méter de l'entreprse et le SI. Le TOGAF cble de plus la défnton des technologes qu répondent le meux aux exgences de l'entreprse. Ces technologes composent alors l'nfrastructure du SI Le DoDAF est un cadre de l'ea du département de la défense amércan ssu du FEAF (Federal Enterprse Archtecture Framework) proposé en 999 pour les agences ou les départements du gouvernement fédéral. Il est centré autour de la préconsaton de l'archtecture SOA et des web servces. De ce fat, l permet d'assurer l'nteropérablté des grands systèmes du SI de la défense amércane. Il propose : - un pont de vue organsatonnel avec les échanges entre acteurs de la défense, - un pont de vue système avec les échanges entre systèmes, - un pont de vue technque avec les technologes préconsées. Le cadre ITIL est une bblothèque de bonnes pratques lées à des exgences de performance et de qualté des systèmes développés. Ces bonnes pratques cblent le servce après-vente des systèmes en s'assurant des performances et de la qualté perçues, d'une part, par le clent du système, et de l'autre, par l'entreprse ttulare du SI contenant le système. Dans ce derner cas, les préconsatons sont auss ben fnancères que lées à la contnuté de servce ou à la dsponblté des systèmes du SI. RM-ODP est un cadre recommandé par l'itu (Internatonal Telecommuncaton Unon). Ce modèle de référence est partculèrement ntéressant du fat qu'l est proche du processus de développement d'un système. RM-ODP fournt en effet un pont de vue de l'nformaton supportée par un système, un pont de vue logcel, un pont de vue de l'ngénere et un pont de vue technque. De plus, ces ponts de vue sont lés. Le len entre ponts de vue préfgure une modélsaton des concepts de chacun des ponts de vue Un cadre partculer de l'ea : l'urbansme Ces dfférents cadres de l'ea sont volontarement peu précs quant à la modélsaton de leurs dfférents ponts de vue. Cette volonté permet d'affcher une plus grande souplesse vs-à-vs des contrantes des multples technques et outls de modélsaton de chaque entreprse [Salnes, 2008]. De plus, l'absence d'un aspect hérarchque de cette modélsaton pour le pont de vue système est pénalsante lorsque le méter d'une entreprse est spécfé par des dzanes de processus méter et lorsque son système nformatque comprend pluseurs centanes d'applcatons. La découpe par nveau est en effet très utle pour rechercher une foncton supportant un processus du SI, par exemple la foncton de créaton d'une commande d'un produt, et obtenr la lste des applcatons du système nformatque qu la réalse. De même lors du développement d'un système, une modélsaton de type hérarchque permet aux archtectes de détecter plus effcacement des éléments du SI afn de les réutlser. 8

20 État de l'art Par rapport à ce manque, un cadre ntéressant de l'ea est celu de l'urbansme [Sassoon, 998]. Le cadre de l'urbansme a été développé en France par des entreprses de talle sgnfcatve au début des années 90. Il offre une parte du pont de vue méter, avec la descrpton des processus du cœur de méter de l'entreprse, et le pont de vue système décrts dans le cadre de référence de Zachman (cf. Fgure 2). Plus précsément, l'urbansme cble à l'ntéreur de ces ponts de vue : - le quo, soent les données, - le comment, soent les fonctons, - le où, sot le réseau, - et une parte du qu, soent les rôles. La spécfcté de ce cadre est l'enrchssement de ces ponts de vue par une approche née de l'urbansme des vlles. Dans l'approche systémque décrte dans le., le SI et la vlle sont en effet consdérées comme des systèmes, pusque tous deux sont consttués d'untés et d'nteractons entre untés [Rosnay, 975]. Les untés et leurs nteractons sont décrtes dans le PLU (Plan Local d'urbansme), ancennement le POS (Plan d'occupaton des Sols), pour la vlle et de façon plus générale pour la commune [PLU, 2008]. Le PLU d'une commune comporte un projet d'aménagement et de développement durable qu défnt les orentatons générales d'aménagement et d'urbansme retenues pour l'ensemble de la commune. Il dot répondre en partculer à des besons d'aménagement de l'espace. Du fat de l'analoge entre vlle et SI [Contn, 2002], l'aménagement de l'espace équvaut à localser les fonctons du SI dans un îlot fonctonnel unque, lu-même nclus dans un quarter fonctonnel unque contenu, à son tour, dans une zone fonctonnelle unque (cf. Fgure 3). Zone Îlot Quarter Fgure 3 : Zone, quarter et îlot du PLU fonctonnel Plus précsément, le PLU permet de découper l'archtecture fonctonnelle du SI par nveau : - Le nveau îlot est le plus bas nveau de découpe du SI. Ce nveau est celu où chaque élément peut être conçu ndépendamment des autres. Dans le cas de la vue fonctonnelle à laquelle le PLU est applqué, un îlot fonctonnel de Geston des contacts avec le clent et un îlot fonctonnel de Geston des commandes pourrat être conçus pour le SI d'une entreprse supportant un processus méter de vente ; - Le nveau quarter est tel que chaque quarter est un regroupement homogène d'îlots quant à la nature de l'nformaton tratée. Dans le cas de l'exemple du SI de vente, les îlots fonctonnels de Geston des contacts avec le clent et de Geston des commandes pourraent être regroupés dans un quarter fonctonnel de Geston de la relaton commercale ; - Le nveau zone est le plus haut nveau de l'organsaton de la vue fonctonnelle du SI. Toujours dans le SI de vente, la zone fonctonnelle Dstrbuton pourrat par exemple être conçue, et nclure le quarter fonctonnel de Geston de la relaton commercale. 9

21 État de l'art Un complément mportant de la défnton du concept de quarter pour la démarche DA4EA (cf..2) est de consdérer un quarter comme un ensemble d'îlots fonctonnels ayant une cohéson forte et un couplage fable [Larman, 2005]. Chaque îlot fonctonnel du PLU est découpé dans la Fgure 4 en parcelles qu correspondent à des fonctons élémentares. L'îlot fonctonnel de Geston des commandes comprendrat par exemple les parcelles fonctonnelles de Créaton d'une commande et de Consultaton d'une commande. De plus, des voes fonctonnelles peuvent exster entre îlots. Ces voes permettent des nteractons entre les îlots fonctonnels. L'exstence d'une voe entre les îlots fonctonnels de Geston des contacts avec le clent et de Geston des commandes est probable dans un SI dédé à la vente. Cette voe représenterat la dépendance fonctonnelle exstante entre la prse de contact avec un clent et la possblté que ce clent at de passer une commande. Îlot Parcelle Voe Fgure 4 : Îlot, parcelle et voe du PLU fonctonnel 2..5 EA et modélsaton Le SI d'une entreprse est un ensemble complexe. Il est en effet composé de pluseurs centanes de systèmes pour de grandes entreprses et de multples nteractons entre ces systèmes. Le processus de cartographe des systèmes du SI (cf. 2..2) permet de résoudre cette complexté par la modélsaton de l'ea du SI. La modélsaton d'après Grady Booch est en effet une représentaton smplfée de la réalté permettant de comprendre un système en cours de développement. Les modèles sont consttués c de dagrammes UML (Unfed Modelng Language) [Booch, 999] [UML, web] ou d'éléments textuels. Les dagrammes UML les plus utlsés sont les dagrammes d'actvté, les dagrammes de classes et les dagrammes de séquence. Dans le cas d'un processus d'usage d'un servce télécom de messagere, ncluant une actvté de fltrage des messages permettant de renforcer la sécurté lors de la récepton d'un message, les utlsatons de ces dagrammes sont par exemple : - le dagramme d'actvtés, llustré par la Fgure 5, dont les concepts représentant un processus sont o un coulor de responsablté avec le rôle responsable de l'actvté (Utlsateur du servce de messagere) o un évènement déclenchant le processus (Demande de messages reçus), o une actvté (Récepton d'un message), o une transton (Fltrage applqué au message succède à Récepton d'un message), o un pont de synchronsaton entre actvtés (après l'évènement Demande de messages reçus et la branche condtonnelle Autre message), o un pont de décson (avant les branches condtonnelles Autre message et Pas d'autre message). 20

22 État de l'art Fgure 5 : Illustraton d'un dagramme d'actvtés UML - le dagramme de classes, llustré par la Fgure 6, dont les concepts sont : o une classe (Sécurté de la messagere Gérer les règles de fltrage), o un attrbut ou une opératon de la classe (l'opératon Créer les règles de fltrage de message), o une relaton de type assocaton ou dépendance (la dépendance dépend de entre les classes Sécurté de la messagere Gérer les règles de fltrage et Sécurté de la messagere Fltrage de message). Fgure 6 : Illustraton d'un dagramme de classes UML - le dagramme de séquence, llustré par la Fgure 7, dont les concepts représentant un scénaro sont : o un scénaro ou nstance de cas d'utlsaton (l'nstance du cas d'utlsaton Sécurté renforcée lors de la récepton d'un message électronque), o un objet ou une nstance de classe (l'nstance de la classe Sécurté de la messagere Gérer les règles de fltrage), o une nteracton entre nstances de cas d'utlsaton et de classe, ou entre nstances de classes, spécfée par un message (le message Créer les règles de fltrage de message entre les nstances des classes Sécurté de la messagere Gérer les règles de fltrage et Sécurté de la messagere Fltrage de message). 2

23 État de l'art Fgure 7 : Illustraton d'un dagramme de séquence UML 22

24 État de l'art Chaque concept défnssant un dagramme UML peut être typé par un stéréotype représenté entre gullemets. Le stéréotype peut par exemple précser un concept du dagramme par son rôle dans l'ea du SI. Par exemple, la classe UML Sécurté de la messagere Gérer les règles de fltrage représente un îlot fonctonnel de type stock défn dans l'ea du SI des servces télécom (cf. Fgure 8). Fgure 8 : Illustraton d'un stéréotype d'une classe UML La traducton d'une relaton de dépendance d'un dagramme de classes UML par une nteracton d'un dagramme de séquence est précsée dans UML par la Sémantque UML Approche dynamque et dagramme de séquence rappelée c-après Cette règle défnt une traducton d'un dagramme de séquence UML décrvant un scénaro d'usage d'un système. Sémantque UML Approche dynamque et dagramme de séquence Dans un dagramme de séquence UML : - une successon d'nteractons ayant pour orgne commune la lgne de ve d'un scénaro, ou la lgne de ve d'une nstance d'une classe représente un ordonnancement temporel de ces nteractons, - une nteracton entre des nstances de classes représente une relaton de dépendance entre classes. 2.2 Vues d'archtecture 2.2. Méta-modélsaton et vues assocées au cadre de l'urbansme Défnton des vues d'archtecture Les vues d'archtecture d'un système dans le cadre de l'urbansme sont la vue fonctonnelle, la vue technque et la vue applcatve [Longépé, 200]. Par rapport au modèle des vues dt "4+" [Kruchten, 995] : - la vue fonctonnelle correspond à la vue des scénaros et à la vue logque, - la vue technque correspond à la vue physque, - la vue applcatve correspond à la vue développement et à la vue processus. La méta-modélsaton permet de modélser les concepts décrvant les vues assocées au cadre de l'urbansme ans que leurs lens. L'ntérêt de ce méta-modèle est que chaque modèle d'archtecture du SI ou d'un système du SI est une nstancaton du méta-modèle [Kleppe, 2003]. L'objectf de réutlsaton d'éléments du SI du nveau modèle est ans faclté par le partage, au nveau méta-modèle, des concepts permettant de décrre ces éléments. Les vues assoces au cadre de l'urbansme sont les vues d'archtecture d'un système auxquelles la vue méter supportée par le SI est ajoutée. L'ensemble des vues recouvre tous les concepts utles à la descrpton d'un SI et de ses systèmes : - une descrpton du méter de l'entreprse dans la vue méter, - une descrpton des fonctons du SI dans la vue fonctonnelle, - une descrpton des applcatons du SI dans la vue applcatve, - une descrpton des technologes de déploement des applcatons du SI dans la vue technque. 23

25 État de l'art SI Méter Fonct onnelle Applcat ve Technque Fgure 9 : Vues du cadre d'urbansme d'un SI Par rapport au développement d'un système du SI, la vue méter ndque le "Pourquo?" de ce développement, la vue fonctonnelle précse le "Quo?", la vue technque décrt le "Avec quo?" et la vue applcatve spécfe le "Comment?". Sot un processus de la vue méter lé à l'usage d'un logement, l serat supporté : - par une vue d'archtecture fonctonnelle recouvrant les fonctons (se laver et se coucher), et, - par une vue d'archtecture technque avec l'nfrastructure chose (salle de bans, chambre à coucher). La vue d'archtecture applcatve du système de type SOA représentant le logement recouvrrat : - la réalsaton sous forme de servce de ces fonctons ntégrant un déploement sur cette nfrastructure (se laver dans la salle de bans et se coucher dans la chambre) Vue méter La vue méter décrt les processus du cœur de méter de l'entreprse et leur structuraton par rapport à l'organsaton de l'entreprse. Cette vue permet de référencer chaque élément du SI par rapport à un processus méter. Les concepts de la vue méter décrts dans le Tableau sont reprs des travaux de défnton de l'analyse d'un processus méter drgés par Francs Alzon à France Télécom R&D. Ces concepts sont dérvés des notons UML d'évènement, de processus, de tâche, d'acteur, d'actvté ou de classe [Booch, 999]. Concept Événement méter Processus méter Tâche méter Entté méter Défnton Notfcaton par un processus méter d une nformaton à un autre processus méter, ou événement éms ou reçu par un acteur méter ou un collaborateur méter. Sa sgnfcaton est drectement perceptble par les dfférents acteurs ndvduels de l entreprse. Il peut être porteur d'nformatons ou de matère. Séquence d'actes réalsée par l'entreprse qu produt un résultat dont la valeur est perceptble et mesurable pour un acteur ndvduel de l'entreprse. Il dot être défn ndépendamment de toute organsaton et de tout système exstant dans l entreprse. Parte de tratement réalsée dans un processus méter, qu d'une part est défne par les nformatons (enttés méter) qu'elle utlse en entrée et qu'elle produt en sorte, par les événements méter reçus et produts, et qu d'autre part respecte certanes règles : l'actvté méter ne met en œuvre qu'une acton prncpale, elle n'est pas nterruptble. Représentaton d'un concept manpulé par l'entreprse dans son actvté. Objet produt ou utlsé par un ou pluseurs processus méter. 24

26 État de l'art Collaborateur méter Procédure méter Actvté méter Donnée méter Représentaton d'un rôle ou d'un ensemble de rôles joué dans la réalsaton des processus méter par un ndvdu ou une unté organsatonnelle, nterne au domane modélsé (par exemple, toute l'entreprse). Un collaborateur méter contrbue à la réalsaton d'un ou pluseurs processus méter (l a un rôle pour chaque processus méter auquel l contrbue), et pluseurs collaborateurs méter peuvent contrbuer à la réalsaton d'un processus méter. Un collaborateur méter émet ou reçot des événements méter. Séquence d'actes réalsée par l'entreprse qu produt un résultat dont la valeur est perceptble et mesurable pour un acteur ndvduel de l'entreprse. Elle dot être défne dépendamment de l'organsaton de l entreprse ou de tout système exstant dans l entreprse. Parte de tratement réalsée dans une procédure méter, qu d'une part est défne par les nformatons (données méter) qu'elle utlse en entrée et qu'elle produt en sorte, par les événements méter reçus et produts, et qu d'autre part respecte certanes règles : l'actvté méter ne met en œuvre qu'une acton prncpale, elle n'est pas nterruptble, et elle est réalsée par un collaborateur méter unque à un moment donné. Représentaton d'un concept manpulé par l'entreprse dans son actvté. Objet produt ou utlsé par une ou pluseurs procédures méter. Tableau : Concepts de la vue méter. La procédure méter est c le résultat de la transformaton d'un processus méter contrant par l'organsaton de l'entreprse [Smonn, 2004]. Chaque tâche du processus est en effet transformée en autant d'actvtés qu'l y a de collaborateurs méter réalsant une parte de la tâche Vue fonctonnelle Un extrat du méta-modèle de la vue fonctonnelle avec les concepts du PLU (cf. 2..4) est proposé dans la Fgure 0. Le concept de donnée logque manpulée par un îlot fonctonnel (cf. Tableau 2) est ntégré dans cet extrat du méta-modèle. La relaton entre une donnée logque et l'îlot qu la produt ou l'utlse est en effet essentelle dans la vue fonctonnelle d'un système. Fgure 0 : Méta-modèle de la vue fonctonnelle enrche du PLU 25

27 État de l'art Les concepts de la vue fonctonnelle sont défns dans le Tableau 2 à partr : - des éléments consttuants du PLU défns dans le 2..4, - des résultats de travaux nternes à France Télécom R&D drgés par Francs Alzon sur l'analyse fonctonnelle d'un système [Ncolas, 2002]. Les termes UML de cas d'utlsaton, de scénaro, de classes et de relaton entre classes [Booch, 999] sont applqués à la vue fonctonnelle. Concept Défnton Cas d'utlsaton Représentaton d'une séquence d'actons d un système fasant ntervenr un ou pluseurs acteurs et produsant un résultat mesurable. Correspond à une grande fonctonnalté d un système. Un système est caractérsé par l ensemble de ses cas d utlsaton. Scénaro Séquence d'nteractons entre objets qu llustre un déroulement partculer d'un cas d'utlsaton. Entté Objet utlsé ou produt par les cas d'utlsaton ; c est sot une noton méter, décrte au nveau de détal nécessare et suffsant pour les besons du système, sot une noton propre au système modélsé, dont l'exstence est généralement due à la prse en compte de l'organsaton. Exgence Traducton d'un beson fonctonnel d'un système. fonctonnelle Interacton entre enttés Ensemble d échanges entre pluseurs enttés pour offrr un servce. Parcelle fonctonnelle Foncton élémentare qu est le nveau de descrpton fonctonnelle le plus bas d'un îlot fonctonnel. Îlot fonctonnel Regroupement de parcelles fonctonnelles qu est le plus bas nveau de découpe du PLU possédant une vue externe. Quarter fonctonnel Regroupement d'îlots fonctonnels homogènes quant à la nature de l'nformaton fonctonnelle tratée au sens large. Zone fonctonnelle Regroupement de quarters fonctonnels qu est le plus haut nveau de découpe du PLU. Interacton entre Ensemble d échanges entre pluseurs îlots fonctonnels réalsant îlots fonctonnels l'usage d'un système. Donnée logque Objet utlsé ou produt par les îlots fonctonnels ; c'est un objet relatf aux enttés défnes par l'utlsaton d'un système. Voe fonctonnelle Vue externe d'une relaton entre îlots fonctonnels offrant un accès à des données logques ou à des tratements sur ces données. Tableau 2 : Concepts de la vue fonctonnelle. Certans concepts décrvant une vue fonctonnelle sont llustrés dans le SI des archtectures de réseau de télécommuncaton [Menaï, 2005]. Les éléments fonctonnels du domane réseau sont en effet des îlots fonctonnels alors que les ponts de référence relant ces éléments fonctonnels correspondent aux voes fonctonnelles. La défnton des données logques du réseau [Menaï, 2006] est fondée sur un sgnal échangé entre deux éléments fonctonnels, sot une nteracton entre îlots fonctonnels. Les deux éléments fonctonnels sont : - l'élément fonctonnel émetteur du sgnal, sot l'îlot fonctonnel à l'orgne de l'nteracton, - l'élément fonctonnel récepteur du sgnal, sot l'îlot fonctonnel cble de l'nteracton. 26

28 État de l'art Cette défnton de la donnée logque, spécfque au réseau, est ntéressante car la donnée est consdérée comme le résultat d'une requête effectuée auprès d'un îlot fonctonnel lors d'une nteracton réalsant un usage du système. Dans le cas général du développement d'un système, la donnée logque est modélsée de façon statque telle que dans le Modèle Logque de Données conçu avec la méthode Merse [Tardeu, 985] Vue technque La vue technque décrt les moyens d'nfrastructure utles au déploement des systèmes du SI. Les concepts de la vue technque décrts dans le Tableau 3 sont conformes aux termes d'exgence, de nœud et de connexon entre nœuds défns dans UML [Booch, 999]. Concept Exgence non fonctonnelle Nœud d'exécuton Protocole Défnton Traducton d'un beson technque ou opératonnel d'un système. Machne physque ou envronnement d'exécuton permettant de supporter l'exécuton des systèmes. Caractérsaton d'un len de communcaton qu permet le transfert d'nformaton entre nœuds d'exécuton. Tableau 3 : Concepts de la vue technque Vue applcatve La vue applcatve représente les composants applcatfs du SI et leurs relatons de dépendance permettant de réalser un système. Les concepts de la vue applcatve du Tableau 4 sont déduts des notons UML de composant, d'nterface et de relaton entre composants [Booch, 999]. Concept Défnton Composant applcatf Réalsaton de fonctons présentant une fnalté fonctonnelle ou une fnalté technque décrte dans des cas d'utlsaton. Il produt des données physques fournes à d'autres composants organques va ses nterfaces. Un composant applcatf peut être l'agrégaton de composants applcatfs. Interacton entre Ensemble d échanges entre pluseurs composants applcatfs pour composants offrr un servce. applcatfs Interface applcatve Vue externe d'un composant applcatf offrant un accès à des données physques ou à des tratements sur ces données. Donnée physque Objet utlsé ou produt par les composants organques qu est la traducton d'une donnée logque sur un nœud d'exécuton. Tableau 4 : Concepts de la vue applcatve. Un concept de la vue applcatve est auss llustré dans le SI des archtectures de réseau de télécommuncaton [Menaï, 2005]. Il s'agt du concept d'organe qu est assocé à celu de composant applcatf. 27

29 État de l'art Règle d'urbansme A chaque concept appartenant à une des quatre vues défnes précédemment, une règle contragnant son nstancaton peut être assocée. Cette règle, dte règle d'urbansme, dot représenter de manère smple une contrante à respecter lors de toutes évolutons du SI [Longépé, 200] [Urba-SI, 2003] [Bonne, 2004]. Pour toutes évolutons de l'archtecture d'un système, les archtectes dovent vérfer que leur archtecture respecte ces règles communes à l'entreprse. Par exemple, le fat qu'une donnée référentelle du SI dot être mse à jour par un seul système du SI est une règle d'urbansme. Défnton : Une règle d'urbansme est une règle paramétrée par des concepts extrats des méta-modèles décrvant chaque vue. Les deux règles d'urbansme suvantes qu cblent les données produtes llustrent cette défnton. Ces règles défnes à France Télécom R&D pour les servces télécom sont dédutes de règles d'urbansme communes à de nombreuses entreprses qu concernent les données référentelles du SI [Urba-SI, 2003]. Ces règles dovent assurer à l'entreprse qu les applque une fablsaton des données de son SI. Règle d'urbansme Donnée produte et îlot fonctonnel n Une donnée logque de la vue fonctonnelle n'est produte que par un seul îlot fonctonnel. Règle d'urbansme Donnée produte et composant applcatf n 2 Une donnée physque de la vue applcatve n'est produte que par un seul composant applcatf. La premère règle d'urbansme est paramétrée par le concept de donnée logque et par le concept d'îlot fonctonnel décrt dans le méta-modèle de la vue fonctonnelle. La seconde règle d'urbansme est paramétrée par le concept de donnée physque et par le concept de composant applcatf de la vue applcatve. Une règle d'urbansme peut auss représenter une règle de développement ou une règle lée au langage utlsé, que ce sot un langage de modélsaton ou un langage de programmaton. Par exemple, une règle défnssant un scénaro de la vue fonctonnelle comme une llustraton d'un cas d'utlsaton est totalement conforme à la sémantque UML. Une règle d'urbansme peut être représentée par une cardnalté dans une assocaton d'un dagramme de classes UML représentant les concepts du méta-modèle des vues. C'est le cas de la Règle d'urbansme Donnée produte et îlot fonctonnel dans la Fgure où la cardnalté de l'assocaton entre la donnée logque et l'îlot fonctonnelle est de pour le rôle îlot producteur. Fgure : Règle d'urbansme Donnée produte et îlot fonctonnel La même règle peut être mplémentée dans des langages lés à l'ngénere des modèles tels que ceux proposés dans KerMeta [Muller, 2005], ATL [Jouault, 2006] ou SmartQVT [SmartQVT, web]. En OCL (Object Constrant Language) [Warmer, 999], la Règle d'urbansme Donnée produte et îlot fonctonnel codée pour la classe UML Donnée logque est la suvante : Context Donnée logque nv self.îlot producteur->sze()=; 28

30 État de l'art La lste des règles d'urbansme proposées dans ce document est dans la table du chaptre Algnement entre la vue méter d'une entreprse et les vues du SI La défnton classque de l'algnement fondée sur l'ea est celle de l'algnement du pont de vue méter d'une entreprse avec son SI. Cette défnton reste néanmons peu précse [Eten, 2006] alors que l'étude de l'algnement entre modèles est devenue nécessare aux archtectes décrvant le résultat de leur concepton à l'ade de modèles [Chen, 2006]. L'algnement à partr de la stratége de l'entreprse est déclné sur le méter et sur le SI en ntégrant les processus méter et les rôles dans l'organsaton de l'entreprse. L'algnement centré sur la stratége de l'entreprse permet dans le cas de l'ea de comparer la prse en compte de cette stratége au nveau méter et dans le SI [Henderson, 993]. L'algnement entre le pont de vue méter d'une entreprse et son SI est auss le prncpe des SIS (Strategc Informaton System) où le cœur de méter ntègre la structure de l'entreprse et sa stratége [Wsemann, 988]. Ce type d'algnement peut prendre en compte de façon complémentare les concepts utles au processus de défnton d'un objectf et au moyen de l'attendre tels que défns par l'ea [Rolland, 999]. Le chox des concepts qu paramètrent cet algnement est spécfque à chaque entreprse [Luftman, 999]. L'ntégraton de l'ea dans un processus de développement permet le partage d'un cadre fonctonnel, d'un cadre technque ou d'un cadre applcatf au nveau d'un SI. Cette ntégraton bénéfce à la réutlsaton d'éléments de ce SI, caractérstque de sa durablté. L'approche SEAM [Wegmann, 2003] qu ntègre ces cadres dans le processus de développement d'un système a pour objectf d'amélorer l'algnement entre le méter de l'entreprse et le SI. L'améloraton est due à une ntégraton multdscplnare (marketng, cœur de méter de l'entreprse, SI) dans l'équpe de développement d'un système du SI et au partage des concepts cblés par l'algnement [Wegmann, 2007]. Il est ntéressant de noter dans SEAM que le modèle d'entreprse est une hérarche de systèmes. Ce prncpe hérarchque est en effet proche de celu de la structure du PLU fonctonnel du SI (cf. 2..4). Cet algnement est dffclement mesurable car l reste ndépendant d'une modélsaton des concepts décrvant l'archtecture fonctonnelle ou l'archtecture technque d'un système. L'algnement défn dans le Busness Motvaton Model [BRG, 2005] est spécfque au pont de vue méter. Ce standard de l'object Management Group est un méta-modèle décrvant les concepts du pont de vue méter de l'ea (stratége, objectf, blan, etc.). L'objectf est de contrôler l'algnement entre le concept d'objectf et les autres concepts du méta-modèle du pont de vue méter. Cet algnement est évalué à partr de la part de marché, des temps d'exécuton d'un processus méter, de la satsfacton du clent, etc. Ce type d'évaluaton de l'algnement entre le pont de vue méter de l'entreprse et le SI peut être réalsé avec des heurstques [Perera, 2005]. Chaque heurstque permet d'alerter l'archtecte d'entreprse en cas de désalgnement lé aux notons de rsque, de coût ou de bénéfce assocés au SI. De même que pour l'approche SEAM, une lmtaton est l'absence de mesures d'algnement entre l'archtecture de la vue méter de l'entreprse et les archtectures décrvant un SI et ses systèmes. Une mesure de cet algnement peut être assmlée à une mesure de couplage [Eten, 2006]. L'algnement de concepts est en effet assmlable à un couplage de ces concepts. De nombreuses mesures de couplage exstent dans le mode orenté objet [Chdamber, 994]. Parm ces mesures de couplage, certanes sont pertnentes dans le cadre d'une approche dynamque du développement de système car elles cblent les nteractons entre classes UML [Brand, 999]. Les mesures applquées aux modèles de données [MacDonell, 997] complètent ces mesures d'algnement. La défnton de mesures d'algnement corrélées au processus de développement d'un système reste cependant complexe [Ktchenham, 995] [Brand, 996]. 29

31 État de l'art Afn de la smplfer, le comportement de la mesure peut être axomatsé [Fenton, 986]. Des axomes sont défns à partr des proprétés que dot vérfer la mesure. Ces proprétés se fondent sur l'ntuton du comportement de la mesure lors de dfférentes hypothèses sur le contexte dans lequel la mesure est effectuée. Une fos défne, la mesure dot alors vérfer les axomes spécfant ce comportement. 2.3 Développement d'un système 2.3. Processus de développement UP Dans une entreprse, le processus de développement d'un système satsfat généralement des normes de qualté telles que celles de l'iso [ISO 2207] [ISO 5504]. C'est le cas du processus de développement UP [Jacobson, 999]. Les vues d'archtecture (cf. 2.2.) propres au développement d'un système, soent les vues fonctonnelle, technque et applcatve, sont ntégrées aux macro-actvtés du processus de développement UP dans la Fgure 2. Exgences Analyse Archtecture Archtecture fonctonnelle Archtecture technque Archtecture applcatve Implémentaton Test Fgure 2 : UP et vues d'archtecture 30

32 État de l'art Le processus de développement UP est un processus tératf et ncrémental. Une tératon cble une macro-actvté alors qu'un ncrément cble un ensemble de macroactvtés qu se succèdent dans le processus. Cette proprété du processus UP permet de défnr des jalons décsonnels du type "STOP / ENCORE" lors du développement ncrémental d'un système tel que décrt dans le modèle en sprale classque [Boehm, 988]. La noton d'ncrément est partculèrement mportante dans un processus de développement. Il permet d'mplquer des acteurs contrbuteurs de macro-actvtés dfférentes dans un même ncrément. Cec mplque qu'ls devennent des partes prenantes de la producton lée à l'ncrément. Un exemple pertnent est celu des macroactvtés de collecte des exgences et d'analyse. La collecte des exgences est réalsée pour un servce télécom par des acteurs du marketng alors que l'analyse est fate par des analystes d'une équpe de développement. L'ncluson dans un même ncrément de ces actvtés favorse la cohérence de l'analyse par rapport aux exgences collectées. L'ntérêt d'une macro-actvté d'archtecture tératve est, par exemple, d'enchaîner : - pour la vue fonctonnelle, la concepton d'îlots fonctonnels et la concepton de données logques manpulées par ces îlots, ou, - pour la vue applcatve, la concepton de composants applcatfs et la concepton de données physques manpulées par ces composants. L'apport de l'aspect tératf est d'assurer une melleure cohérence globale du modèle d'archtecture fonctonnelle ou du modèle d'archtecture applcatve. Le Tableau 5 défnt le modèle produt lors de chaque macro-actvté du processus UP [Jacobson, 999] ntégrant les vues d'archtecture (cf. 2.2.). Macro-actvté Exgences Analyse Archtecture fonctonnelle Archtecture technque Archtecture applcatve Implémentaton Test Modèle Modèle de cas d'utlsaton Modèle d'analyse Modèle d'archtecture fonctonnelle Modèle d'archtecture technque Modèle d'archtecture applcatve Modèle de déploement Modèle d'mplémentaton Modèle de test Tableau 5 : Macro-actvtés UP et modélsaton. Il est ntéressant de noter l'ajout de l'ea, entre autres dscplnes, à RUP dans EUP (Enterprse Unfed Process) [Ambler, 2005]. L'objectf de cet ajout est de proposer des modèles d'archtecture de référence aux archtectes de système. Cette archtecture de référence est défne comme un patron avec des artéfacts permettant leur usage. Certanes macro-actvtés du processus de développement UP possèdent un aspect statque et un aspect dynamque. C'est le cas classque de l'analyse défne par un aspect statque et par un aspect dynamque dans les technques de modélsaton objet [Rumbaugh, 99]. Dans [Roques, 2004], l'aspect statque de la macro-actvté d'analyse cble les classes UML alors que l'aspect dynamque recouvre leur nstancaton lors du déroulement d'un scénaro décrvant l'usage d'un système. Globalement, les cas d'utlsaton d'un système sont à l'orgne des aspects statques des macro-actvtés et les scénaros llustrant ces cas d'utlsaton sont à l'orgne de l'aspect dynamque des macroactvtés. 3

33 État de l'art Aspect dynamque d'un système La vue prvlégée pour guder les travaux d'archtecture d'un système de type archtecture orentée servce (SOA : Servce Orented Archtecture) est la vue méter telle que défne par le Busness Process Management (BPM) [Burlton, 200]. Pour une entreprse qu fournt des servces de télécommuncaton, cette vue content par exemple les procédures d'utlsaton d'un servce télécom tel qu'un servce de téléphone, un servce de messagere ou un servce de vdéo à la demande [Bertn, 2007]. L'entreprse construt un SI et ses systèmes afn de contrbuer à la réalsaton de chaque processus de son cœur de méter (cf..). Afn de réalser un processus, la démarche est de concevor un ensemble de séquences strctement ordonnées d'appels à des servces fourns par les systèmes composant le SI. Par exemple, la réalsaton d'un processus de commande de produt est réalsée par un appel à un servce de créaton d'une commande, pus un appel de créaton d'un clent et enfn un appel de recherche d'un artcle dans le catalogue de produts. Une lacune dans cette vue qu décrt les processus du cœur de méter de l'entreprse est l'absence de l'aspect dynamque du SI [Kasler, 2005]. La vue méter ne peut en effet représenter les flux entre les systèmes du SI. Afn d'llustrer la dffculté de défnr de manère optmale les servces propres à la réutlsaton dans une archtecture SOA, l'archtecture d'un système est représentée caprès par l'analoge avec l'usage d'un logement comme processus méter et avec un logement à réalser comme système du SI. La réalsaton de ce processus méter équvaut à accéder à une séquence de servces où chaque servce est déployé dans une des pèces du logement. L'accès à un servce se fat à partr d'un coulor qu joue le rôle de bus de servce en offrant une possblté d'accès à tous les servces déployés dans chaque pèce du logement. Par exemple, la séquence temporellement ordonnée de servces fourns par le logement décrt Fgure 3 réalse le processus méter se coucher dans un logement :. se laver dans la salle de bans, 2. se coucher dans la chambre à coucher. Chambre à coucher Chambre à coucher 2 Cusne 2 Se coucher dans un logement Salle à manger Salle de bans Salon Fgure 3 : Processus se coucher dans un logement et séquence ordonnée de servces 32

34 État de l'art Le prncpal apport de l'aspect dynamque est de reposer sur l'étude des dépendances entre fonctons. Dans l'llustraton du logement, la foncton se coucher peut dépendre drectement de la foncton se laver. Pour l'archtecte, cette dépendance sgnfe que l'affrmaton "se coucher nécesste de se laver" est plus cohérente avec le processus d'usage du logement que la séquence ordonnée représentée dans la Fgure 3. L'archtecte peut en dédure un accès ndrect au servce de la vue applcatve se laver dans la salle de bans va le servce se coucher dans la chambre, et non plus un accès drect. Les conséquences sur la vue applcatve représentées Fgure 4 sont une utlsaton optmsée du coulor du fat de l'accès ndrect à la salle de bans. Le passage dans le coulor, assmlé dans l'allégore à un bus de servces [Robnson, 2004], est ans dmnué. Ce bus joue un rôle de médateur entre l'utlsateur de la mason et la mason. De plus, la vue technque est optmsée en postonnant la salle de bans entre les deux chambres afn de déployer dans chaque chambre la réalsaton de cette dépendance fonctonnelle. Chambre à coucher 2 Salle de bans Chambre à coucher 2 Se coucher dans un logement Cusne Salle à manger Salon Fgure 4 : Processus se coucher dans un logement et dépendance de servces Le processus orenté clent est une soluton permettant de répondre à l'évolutvté des marchés et des technologes. La méthode BPR (Busness Process Reengeneerng) [Schael, 997], ssue de la réngénere [Hammer, 993], permet de modélser les processus orentés clent ncontournables pour l'entreprse. La réponse technologque est le fonctonnement en réseaux coopératfs afn de répondre à la demande du clent. Ce fonctonnement nécesste néanmons pour Thomas Schael une améloraton au nveau fonctonnel. L'aspect dynamque apparaît auss dans le modèle archtectural en couches nspré du modèle OSI (Open Systems Interconnect) [Zmmermann, 980]. Ce modèle en couches est applqué en nformatque aux archtectures N-ter. La localsaton sur une couche de chaque élément de l'archtecture d'un système permet de mettre en œuvre des règles d'nteracton entre éléments de couches dfférentes. La structure en couches stablse ans une archtecture. La couche de présentaton d'un système, ou IHM (Interface Homme-Machne), est la plus mpactée par l'aspect dynamque d'un système. Cette couche de présentaton est spécfée dynamquement par une cnématque des écrans offerts à l'utlsateur du système [Armour, 200]. Les scénaros d'usage d'un système sont ans classquement utlsés dans les méthodes de concepton des IHM [Caroll, 995]. Les nteractons successves entre un utlsateur d'un système et le système dovent en effet représenter un usage spécfé du système. La réutlsaton de composants peut auss bénéfcer de la décomposton a posteror de scénaros d'usage d'un système [Rolland, 998]. 33

35 État de l'art Développement d'un système et approche MDA La modélsaton est une soluton à la complexté dans l'approche systémque présentée dans l'ntroducton (cf..), que ce sot la complexté d'un SI ou la complexté d'un système. Le chox de l'urbansme comme cadre de l'ea permet de modélser de façon hérarchque les vues d'un SI grâce aux concepts du PLU. Ces mêmes vues applquées à un système de ce SI dovent donc auss être modélsées afn d'être smplfées. Le chox de l'ngénere des modèles permet de concevor des solutons de modélsaton de l'archtecture d'un système en prenant en compte la contrante de modèles des vues d'un SI cble. La concepton drgée par les modèles (Model Drven Desgn) permet en effet de développer des systèmes à partr de modèles décrvant le comportement des systèmes représentés par des scénaros, donc par l'aspect dynamque de ces systèmes [Jézéquel, 2008]. Dans un processus de développement, l'approche d'ngénere des modèles cble généralement l'archtecture applcatve détallée, la génératon de code utle à la macroactvté d'mplémentaton, et les tests. Pour l'archtecture applcatve détallée, la projecton de chaque composant applcatf sur une couche applcatve (couche présentaton, couche d'accès aux données, etc.) est détallée à l'ade d'un envronnement archtectural propre à chaque couche. Les approches MDE [Frankel, 2003] ou MDA [MDA, web] favorsent l'ntégraton d'envronnements archtecturaux applcatfs durant un processus de développement de système [Guelf, 2004]. Concernant les tests, l'approche MDA permet de tester les systèmes générés à partr de transformatons de modèles en valdant ces transformatons [Fleurey, 2004]. L'approche MDA est une norme proposée par l'omg (Object Management Group) qu cble la transformaton de modèles. Dans le cadre proposé par l'omg, la plate-forme est lée à un envronnement d'exécuton (Java, Corba, etc.). Les modèles mpactés sont le PIM (Platform Independent Model), le PSM (Platform Specfc Model) et le modèle de la plate-forme [Mller, 2003]. L'utlsaton méthodologque de ce modèle de plate-forme sous le sgle de PDM (Platform Descrpton Model) est défne par le fat que le PSM est une confguraton du PIM pour un PDM donné [Gervas, 2002]. L'objectf de l'approche MDA est de s'affranchr de l'hétérogénété des plates-formes d'exécuton. L'dée représentée dans la Fgure 5 est de transformer un modèle ndépendant de la plate-forme (PIM) en un modèle spécfque à cette plate-forme (PSM) en contragnant cette transformaton par un modèle défnssant la plate-forme (PDM). Cette plate-forme peut auss être prse en compte drectement dans le PSM, c'est-à-dre sans transformaton d'un modèle ndépendant des contrantes de la plate-forme. Un autre modèle est défn dans l'approche MDA pour représenter les exgences fonctonnelles du système à développer. Ce modèle est le CIM (Computaton Independent Model). Ce modèle peut être transformé en un PIM. Cette transformaton non contrante représente le passage des exgences vers l'analyse et la concepton défnes dans UP. La transformaton du PIM vers le PSM représente dans l'approche MDA le passage de la concepton générale du système à la concepton détallée, dernère étape avant le codage d'une applcaton [Blanc, 2005]. 34

36 État de l'art PIM PDM PSM Fgure 5 : PIM, PDM et PSM dans l'approche MDA Les transformatons de modèle ont pour paramètres les concepts de chaque vue du SI (cf. 2.2.). Les méta-modèles utles à chaque transformaton, soent ceux du PIM, du PSM et du PDM, sont extrats des méta-modèles des vues. Ces méta-modèles peuvent être représentés par des dagrammes de classes UML. Les transformatons de modèles lées au développement d'un système peuvent ans être représentées par un dagramme de classes représentant les concepts mpactés. L'ngénere des modèles permet d'ntégrer au meux la méta-modélsaton des concepts décrvant un système du SI [Menaï, 2005]. De plus, elle permet de représenter une macro-actvté du processus UP par une transformaton de modèle fondée sur les concepts défnssant les dfférentes vues. 2.4 Concluson Une premère dffculté soulgnée dans l'état de l'art est la qualté de la concepton des éléments à réutlser dans le SI. Une soluton à cette dffculté rentre dans le cadre du SOEA (Servce Orented Enterprse Archtecture) [Grgoru, 2007]. Les composants conçus par les archtectes d'entreprse ou les urbanstes du SI sont mplctement les composants approprés à une archtecture SOA [Grgoru, 2006]. La démarche DA4EA présentée dans la thèse offre une soluton de défnton des servces à partr de la vue fonctonnelle de l'ea. De même, la prse en compte par l'archtecte d'un système des modèles réalsés par les archtectes d'entreprse est complexe. La premère rason est l'absence d'une modélsaton pertnente de l'ea d'un SI. Une seconde rason est une prse en compte non automatsée de l'ea lors du développement d'un système. Cette ntégraton des composants de l'ea peut bénéfcer du cadre de l'urbansme d'un SI et de l'ngénere des modèles. La démarche EA4UP décrte dans la thèse recouvre l'ntégraton de l'ea lors du développement d'un système. Dans cette démarche, l'approche MDA est chose pour transformer un modèle ndépendant d'une plate-forme en un modèle dépendant de cette plate-forme. La défnton de la plate-forme, ou PDM, contragnant la transformaton de modèles est étendue dans la démarche EA4UP. 35

37 État de l'art Une complexté méthodologque est de plus ndute par la modélsaton en parallèle des données et des tratements telle que préconsée dans Merse [Tardeu, 985]. Pour résoudre cette complexté, la démarche EA4UP est fondée sur l'aspect dynamque du système. La concepton d'une séquence de fonctons réalsant un scénaro d'usage d'un système précède en effet dans la démarche EA4UP une modélsaton des données manpulées par chaque foncton durant ce scénaro. La prse en compte plus drecte de la dynamque des scénaros d'utlsaton des systèmes lors de leur concepton a pour objectf d'amélorer, au nveau fonctonnel, la réutlsablté d'éléments du SI. La décomposton des scénaros proposée est de plus réalsée a pror par une défnton de la vue fonctonnelle cble du SI. Les scénaros d'usage d'un système sont de ce fat des éléments mportants en entrée des démarches DA4EA et EA4UP. Une autre dffculté rappelée dans l'état de l'art est de défnr précsément un algnement et d'en dédure une mesure. Des concepts du méta-modèle des vues de l'urbansme sont sélectonnés afn de défnr des algnements propres aux démarches DA4EA et EA4UP. Cette soluton est d'abord proposée dans le cadre d'une mesure de l'algnement entre la vue méter d'une entreprse et la vue fonctonnelle d'un SI dans la démarche DA4EA. Dans le trosème pont de la contrbuton de la thèse, cette soluton est mse en œuvre pour une mesure d'algnement permettant d'évaluer l'écart entre la vue fonctonnelle urbansée du SI et l'archtecture fonctonnelle conçue pour un système de ce SI. Cette mesure d'algnement fonctonnel est étudée c dans le cadre théorque de la théore de l'nformaton [Shannon, 948]. Les voes entre éléments fonctonnels conçues dans la vue fonctonnelle du SI sont consdérées lors de l'élaboraton de la mesure à un canal de communcaton. Pour chaque scénaro d'usage d'un système, la vue fonctonnelle du SI a alors pour rôle de transmettre chaque nteracton du scénaro. La qualté de la transmsson dépend du nveau (zone, quarter, îlot) de la voe entre éléments fonctonnels utlsée par l'nteracton. La mesure d'algnement chose est l'nformaton mutuelle moyenne défne par Claude Shannon qu évalue la qualté de la transmsson. L'ntérêt de cette approche est de défnr une mesure mathématque d'un algnement dépendant des concepts du méta-modèle des vues du SI ou d'un système. 36

38 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI 3. La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI 3. Prncpes S l'llustraton du logement à réalser est reprse (cf ) pour présenter la démarche DA4EA, l'objectf serat d'assster l'archtecte fonctonnel devant concevor un logement modèle. La démarche DA4EA ade l'archtecte de ce modèle fonctonnel : - en stablsant son archtecture grâce à un typage des fonctons d'usage d'un logement (les fonctons se coucher et aménager les combles ne sont pas du même type dans le processus d'usage d'un logement pusque les cycles de ve des deux fonctons sont dfférents), - en offrant un outl de regroupement de fonctons proches dédées à l'usage d'un logement (un ensemble de fonctons dédées au couchage, un ensemble de fonctons dédées aux repas, etc.). 3.. La vue fonctonnelle dédute de la vue méter ou algnée avec la vue méter? L'urbansaton de la vue méter d'une entreprse et l'urbansaton de la vue fonctonnelle d'un SI défnes dans le respectent toutes les deux la stratége de l'entreprse. Ce respect commun défnt un len entre la vue méter supportant un SI et la vue fonctonnelle de ce SI. Dans le cadre d'une urbansaton, la vue fonctonnelle est généralement dédute de la vue méter. Cette vue fonctonnelle peut auss être conçue de manère spécfque. Dans ce derner cas, le len entre les deux vues est concrétsé par l'évaluaton de leur algnement. La déducton d'une vue fonctonnelle à partr d'une vue méter est consdérée comme une transformaton, réalsée par des experts, des axes stratégques méter vers la vue fonctonnelle ou vers la vue technque. Cette transformaton est représentée dans [Longépé, 200] par un enchaînement de dagrammes d'ishkawa représentant les axes stratégques de la vue méter ou de la vue fonctonnelle. La noton de transformaton dans le cadre de l'urbansme nécesste auss de concevor un len explcte entre des concepts du méta-modèle décrvant chacune des vues. Chaque len est complété par des règles d'urbansme. Un exemple de règle pourrat être de dédure un îlot de la vue fonctonnelle à partr d'une tâche de la vue méter et d'une entté méter produte par la tâche. 37

39 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Par exemple, pour les SI de France Télécom, un len de déducton devrat être conçu entre les processus décrts dans etom [etom, web] par le TMF (TeleManagementForum), dont un extrat cblant le clent est proposé Fgure 6, et la vue fonctonnelle des SI de France Télécom représentée dans la Fgure 7 pour le domane lé au clent de l'opérateur. Sales Order Handlng Problem Handlng Customer QoS Management Invocng/ Collecton Customer Care Processes Processus Fgure 6 : Extrat de la vue méter etom customer Sales Commercal Referental Loyalty and retenton Order Capture Customer Support Customer QoS Management Fgure 7 : Extrat de la vue fonctonnelle du SI de France Télécom Le len entre ces deux vues est mmédat entre le processus Sales d'etom et le bloc fonctonnel Sales de la vue fonctonnelle du SI de France Télécom. Par contre, le bloc fonctonnel Commercal Referental qu est dédut de l'ensemble des processus Customer Care Processes soulgne l'mportance de la geston du clent dans le SI de France Télécom. Cette mportance est mse en relef par des applcatons spécfques à la geston du clent. La vue fonctonnelle des SI de France Télécom est donc dédute drectement de la vue méter tout en ntégrant le pérmètre fonctonnel réalsé par les applcatons de ses SI. Dans le cas de la concepton spécfque de la vue fonctonnelle d'un SI, la vue fonctonnelle est conçue par un urbanste fonctonnel expert d'une zone fonctonnelle. L'urbanste ntègre drectement la stratége marketng ou les évolutons technologques, lorsque le cœur de méter de l'entreprse le nécesste, lors de la concepton de la vue fonctonnelle de sa zone. La vue fonctonnelle du SI des servces télécom de France Télécom est une llustraton de cette concepton spécfque. Les zones de cette vue fonctonnelle conçues par les urbanstes de France Télécom R&D sont représentées dans la Fgure 8. 38

40 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Zone fonctonnelle Fgure 8 : Extrat de la vue fonctonnelle du SI des servces télécom de France Télécom Ces zones supportent les processus d'usage d'un servce télécom. La Fgure 9 représente un de ces processus, sot le processus d'envo de message électronque décrt dans un dagramme d'actvtés UML par Emmanuel Bertn lors de ses travaux à France Télécom R&D sur la concepton de la vue méter lée à l'usage des servces télécom. Fgure 9 : Extrat de la vue méter du SI des servces télécom de France Télécom Les zones fonctonnelles du SI des servces télécom entourées dans la Fgure 8 supportent le processus d'envo de message électronque. Ces zones fonctonnelles sont la zone Messagng pour l'édton et l'envo du message et la zone Personal & communty nfo pour la geston de l'adresse du destnatare appartenant au carnet d'adresse de l'expédteur du message. 39

41 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI L'exstence propre d'une vue fonctonnelle d'un SI nécesste néanmons d'être algnée sur la vue méter de l'entreprse. Cet algnement, qu est un cas partculer de l'algnement du cœur de méter de l'entreprse avec le SI (cf ), représente en effet la cohérence de ces deux vues quant à la prse en compte de la stratége de l'entreprse. La concepton d'une vue fonctonnelle d'un SI avec la démarche DA4EA proposée dans ce chaptre est une concepton spécfque. Cette concepton tent donc compte de l'algnement de la vue fonctonnelle avec la vue méter Descrpton d'ensemble de la démarche DA4EA La démarche DA4EA décrte Fgure 20 recouvre les actvtés suvantes : - La concepton par les urbanstes de chaque zone des îlots fonctonnels et de leurs parcelles, des voes de la vue fonctonnelle de la zone. Cette concepton d'expert prend en compte la stratége de l'entreprse ; - Le typage des îlots fonctonnels réalsé par l'urbanste, expert de la zone contenant les îlots. L'actvté permet de créer, de valder ou d'nvalder des voes entre îlots ; - La mesure de l'algnement entre la vue fonctonnelle et la vue méter. Le blan réalsé à partr de cette mesure permet de fare évoluer le pérmètre fonctonnel des îlots ou de modfer les voes qu les relent ; - La concepton des quarters fonctonnels fondée sur une approche dynamque cblant les îlots fonctonnels conçus. 40

42 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Fgure 20 : Démarche DA4EA L'ensemble des actvtés autour des îlots et des voes de la démarche DA4EA nécesstent une approche ncrémentale (cf. 2.3.). Grâce à la mesure de l'algnement de la vue fonctonnelle, l'urbanste de la zone concernée peut : - réajuster la défnton des parcelles d'un îlot, - ajouter ou supprmer une voe entre deux îlots. Deux actvtés de la démarche DA4EA sont automatsables. La stablsaton des îlots et des voes à partr du typage des îlots et la concepton des quarters sont en effet le résultat de l'applcaton de règles d'urbansme. Afn d'mplémenter ces règles, l'approche MDE [Frankel, 2003] et le langage QVT [QVT, web] sont choss. L'ntérêt de cette approche est de bénéfcer du méta-modèle des vues d'urbansme et des règles d'urbansme qu lu sont assocées pour créer la transformaton de modèle. 4

43 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI 3.2 Concepton experte des zones et des îlots du PLU fonctonnel La concepton des zones et des îlots du PLU fonctonnel est une actvté complexe de l'urbansaton. La complexté nat de l'ntégraton concrète de la stratége de l'entreprse dans la vue fonctonnelle d'un SI qu est abstrate. Le contenu de cette actvté entourée dans la Fgure 2 est décrt dans ce paragraphe sans être approfond du pont de vue méthodologque. Fgure 2 : Actvté de concepton experte des zones, des îlots et des voes fonctonnels dans la démarche DA4EA La découpe en zones fonctonnelles supportant un processus méter est le résultat du traval d'un groupe d'experts de ce SI. La caractérstque mportante de cette découpe est de ne prendre en consdératon que l'aspect fonctonnel du SI. La dffculté est de dssocer le fonctonnel, vu de l'utlsateur de ce SI, du fonctonnel dont l'utlsateur bénéfce de façon mplcte. Par exemple, la foncton envoyer un message électronque est perçue de l'utlsateur alors que la foncton transmettre à haut débt bénéfce à l'envo de son message, sans être explcte, a pror, à l'utlsateur. L'mpact de la stratége de l'entreprse permet à ce groupe d'experts de soulgner l'mportance d'un axe fonctonnel stratégque en le recouvrant par une zone fonctonnelle. Dans l'llustraton de la messagere, un axe stratégque pourrat être de proposer à un utlsateur d'unfer ses messageres sur le réseau moble, le réseau fxe et le réseau nternet. La stratége marketng serat alors d'offrr un servce télécom permettant à un utlsateur de consulter ses messages, quelque sot le réseau auquel l est connecté. La créaton d'une zone messagere ntégrant l'unfcaton soulgnerat son mportance pour l'entreprse. La défnton des îlots d'une zone fonctonnelle par l'urbanste expert de la zone dot auss être conforme à la stratége de l'entreprse. S la stratége de l'opérateur de télécommuncaton est de proposer une sécurté renforcée lors de la récepton d'un message électronque, l'urbanste fonctonnel devrat soulgner cet axe stratégque par la créaton d'un îlot fonctonnel de sécurté de la messagere. Cet îlot comprendrat les parcelles suvantes : Fltrer un message par rapport à l'objet du message, Fltrer le message par rapport à l'expédteur du message, Créer les règles de fltrage de message. 42

44 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI La concepton de voes entre îlots est plus dffcle pour l'urbanste. Elle nécesste de prendre en compte la dépendance fonctonnelle d'un îlot vs-à-vs d'un autre îlot. Cette dépendance dot être cohérente avec son nstancaton au sens UML dans une approche dynamque (cf ) de la concepton de la vue fonctonnelle. La cohérence des voes fonctonnelles avec les nteractons entre nstances d'îlots fonctonnels durant un scénaro d'utlsaton du système est spécfée dans la règle d'urbansme suvante. La Règle d'urbansme Interactons et voes nécesste le typage de l'nteracton entre deux îlots fonctonnels défn c-après. Défnton : une nteracton entre nstances d'îlots fonctonnels est : - de type <<requête>> s l'nteracton est une demande, ou s l'nteracton correspond à l'émsson de paramètres d'entrée d'une requête, - de type <<réponse>> s l'nteracton est une réponse à une demande ou s l'nteracton correspond à l'émsson de paramètres de sorte d'une requête. Règle d'urbansme Interactons et voes n 3 Chaque nteracton entre nstances d'îlots fonctonnels spécfée à partr d'un scénaro d'un cas d'utlsaton d'un système dot être conforme avec une voe entre îlots fonctonnels : - s l'nteracton de type requête est adressée à une nstance de l'îlot fonctonnel I 2 à partr d'une nstance de l'îlot I, elle nécesste une voe de l'îlot I vers l'îlot I 2. - s l'nteracton de type réponse est adressée à une nstance de l'îlot fonctonnel I à partr d'une nstance de l'îlot I 2, elle nécesste une voe de l'îlot I vers l'îlot I 2. Dans les deux cas, l'îlot I dépend de l'îlot I 2. Avec une modélsaton formulée avec le langage UML, cette règle sgnfe que le dagramme de séquence représenté dans la Fgure 23 est conforme au dagramme de classe représenté dans la Fgure 22. Dans ces dagrammes : - un îlot fonctonnel est représenté par une classe UML stéréotypée "îlot fonctonnel", - une voe d'un îlot fonctonnel vers une autre est une dépendance UML stéréotypée "dépend de", - une nteracton de type requête est stéréotypée "type requête", - une nteracton de type réponse est stéréotypée "type réponse". Fgure 22 : Modèle d'îlots fonctonnels de référence 43

45 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Fgure 23 : Dagramme de séquence conforme à un modèle d'îlots fonctonnels L'nteracton de type requête est une opératon au sens UML offerte par l'îlot cble de cette nteracton. Cet îlot est auss la source de l'nteracton de type réponse dédute de la requête. Supposons qu'un axe stratégque du marketng sot d'assocer la récepton d'un message à une offre de sécurté pour l'utlsateur qu reçot le message. Du fat de cet axe stratégque, s l'urbanste crée un îlot fonctonnel de geston de la sécurté de la messagere, l'îlot fonctonnel de Sécurté de la messagere dépendrat de l'îlot de Récepton d'un message. La sécurté de la messagere est en effet responsable de la récepton d'un message, et non l'nverse. La Fgure 24 représente dans un dagramme de classes UML cette dépendance. Dans ce dagramme de classes, une parcelle fonctonnelle est une méthode de la classe UML représentant l'îlot auquel elle appartent. Fgure 24 : Illustraton de la dépendance d'îlots de la vue fonctonnelle d'un SI 44

46 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Cette dépendance entre îlots est nstancée au sens UML lors d'un scénaro du servce télécom de messagere électronque. Le dagramme de séquence UML de la Fgure 25 représente un scénaro possble nstancant la dépendance entre les îlots Sécurté de la messagere et Récepton d'un message. Dans le dagramme de séquence, - une nteracton de type requête ayant pour cble un îlot fonctonnel est lbellée par l'nttulé de la parcelle utlsée dans cet îlot, - une nteracton de type réponse ayant pour source un îlot fonctonnel est lbellée par l'nttulé de la parcelle utlsée dans cet îlot. Fgure 25 : Illustraton d'un scénaro nstancant des îlots dépendants de la vue fonctonnelle d'un SI Le scénaro de mse en œuvre de fonctons de sécurté lors de la récepton d'un message est représenté par une nteracton ayant pour source une nstance de l'îlot fonctonnel Sécurté de la messagere et pour cble une nstance de l'îlot fonctonnel de Récepton d'un message. Cette nteracton succède à celle de fltrage d'un message pusque le fltrage est applquée lors la récepton du message. 45

47 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI 3.3 Concepton des îlots du PLU fonctonnel Un premer objectf de la démarche DA4EA est d'assster l'urbanste fonctonnel lors de l'actvté de concepton des voes entre îlots. La soluton proposée est fondée sur le typage de chaque îlot fonctonnel par rapport à la durée de ve de son nstance. Un modèle type des voes entre des îlots de type dfférent permet l'attente de l'objectf Défnton du typage d'un îlot fonctonnel Le prncpe du typage est ssu du concept de couche archtecturale (cf ). Le typage de chaque élément permet la localsaton de l'élément sur une couche. Ce prncpe est applqué à la concepton des îlots fonctonnels et des voes qu les relent. L'actvté de typage d'un élément fonctonnel entourée dans la Fgure 26 peut caractérser : - un îlot fonctonnel ou - une donnée logque produte ou utlsée par un îlot fonctonnel [INPI 0467] [INPI 05928] [INPI 06470]. Le typage d'un îlot fonctonnel ou d'une donnée de la vue fonctonnelle est commun respectvement à toutes ses parcelles ou à tous ses attrbuts. Le prncpe de ce typage est de consdérer la dépendance de la durée de ve d'une nstance au sens UML de l'élément fonctonnel par rapport à celle du processus supporté. Fgure 26 : Actvté de typage des îlots fonctonnels dans la démarche DA4EA Défnton : le typage des îlots fonctonnels est le suvant : - un îlot fonctonnel est de type flux s la durée de ve d'une nstance de chacune de ses parcelles est dépendante du processus supporté ; - Un îlot fonctonnel est de type stock s la durée de ve d'une nstance de chacune de ses parcelles est ndépendante du processus supporté. 46

48 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI S T est l'ensemble des deux types d'îlots fonctonnels, s P(T) est l'ensemble des partes de T, c'est-à-dre l'ensemble des sous-ensembles de T, et s I f est l'ensemble des îlots fonctonnels du PLU, alors le typage t d'un l'îlot fonctonnel peut être représenté de la manère suvante : t : I f P T a t; t ( ) P( { flux, stock} ) Équaton 3- La dffculté du typage d'un îlot est d'avor un lbellé non ambgu pour chacune de ses parcelles. Le chox d'une sémantque de référence telle que le modèle Create Read Update Delete (CRUD) et des règles assocées [Klov, 994] permet de clarfer le sens du verbe du lbellé la parcelle. En ce qu concerne le complément du verbe, sa défnton dot lever toutes ambguïtés sur le lbellé de la parcelle. Par exemple, la parcelle Créer un message correspond-elle à la créaton de la structure du message ou à sa date d'envo? Ce type d'nterrogaton sur l'ambgüté des lbellés des parcelles d'un îlot est fréquent durant toute la phase de typage d'un îlot fonctonnel. L'objectf du typage des îlots est de stablser l'archtecture fonctonnelle du PLU par un modèle en couches (cf ). Le typage des îlots fonctonnels a pour but d'assocer chaque îlot à une couche flux ou à une couche stock de l'archtecture fonctonnelle d'un système. Afn de stablser les voes entre îlots, la Règle d'urbansme Flux et stock contrant l'orentaton des voes. La pertnence d'un typage d'un élément fonctonnel est en effet lée à l'exstence d'un pattern de dépendance entre des éléments fonctonnels de type dfférent. Règle d'urbansme Flux et stock n 4 S un îlot fonctonnel de type flux et un îlot fonctonnel de type stock sont dépendants, alors l'îlot fonctonnel de type flux dépend de l'îlot fonctonnel de type stock. Fgure 27 : Règle de dépendance d'îlots fonctonnels suvant leur type Dans l'llustraton lée à la messagere où le processus supporté est celu de l'usage d'une messagere électronque, l'îlot fonctonnel Sécurté de la messagere est de type flux pour les parcelles Fltrer un message par rapport à l'objet du message, Fltrer le message par rapport à l'expédteur du message car toutes nstances de ces parcelles ont une durée de ve dépendante du processus d'usage d'une messagere électronque. L'îlot fonctonnel sécurté de la messagere est de type stock pour sa parcelle Créer les règles de fltrage de message. La créaton de règles de fltrage des messages ndésrables est en effet transverse aux dfférents usages d'un servce de messagere électronque. Le cycle de ve des nstances de cette parcelle est donc ndépendant de celu de l'usage du servce. L'îlot fonctonnel Récepton d'un message défn par la parcelle Recevor un message est de type flux pusque cette parcelle a un cycle de ve dépendant de l'usage d'un servce de messagere 47

49 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI t t D'après l'équaton 3-, la formulaton de ce typage est la suvante : ( Sécurté de la messagere) = { Flux, Stock} ( Récepton d' un message) = { Flux} Transformaton des îlots du PLU fonctonnel contrante par le typage Certans îlots typés par les experts d'une zone fonctonnelle peuvent posséder des parcelles de type dfférent. Dans ce cas, l y a scsson de l'îlot en autant d'îlots que de types dstncts de ses parcelles. Cette sous-actvté est la premère parte de l'actvté de concepton automatsée des îlots et des voes fonctonnels entourée dans la Fgure 28. Fgure 28 : Sous-actvté de transformaton des îlots fonctonnels par typage dans la démarche DA4EA La foncton s défne c-après représente la scsson d'un îlot fonctonnel. Défnton : s T est l'ensemble des types d'îlots fonctonnels, s I f est l'ensemble des îlots fonctonnels du PLU et s P(I f x T) est l'ensemble des partes de I f x T, c'est-à-dre l'ensemble des sous-ensembles de I f x T, alors la scsson s de l'îlot fonctonnel en n îlots fonctonnels, dont de type t et n de type t n, peut être représentée de la manère suvante : s : I a f P ( I T ) f {(, t ),..., (, t )}; t( ) = { t },..., t( ) = { t } n n Équaton 3-2 Dans la démarche DA4EA, l exste deux types d'îlots fonctonnels, soent le type flux et le type stock. Tous les îlots fonctonnels défns par la foncton s sont dépendants les uns des autres. Les parcelles d'un même îlot sont fortement couplées d'un pont de vue fonctonnel. Ce couplage est représenté fonctonnellement par une voe entre les îlots ssus de la scsson. Le modèle des voes ssues de la scsson d'îlots fonctonnels est conforme à la règle de dépendance entre îlots fonctonnels suvant leur type défn dans la Règle d'urbansme Flux et stock du n n 48

50 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Dans l'llustraton chose de sécurté lée à la récepton d'un message, s l'îlot fonctonnel Sécurté de la messagere est à la fos du type flux et du type stock, alors cet îlot dot être scndé en deux îlots fonctonnels : - Sécurté de la messagere Fltrage de message de type flux défn par les parcelles Fltrer un message par rapport à l'objet du message et Fltrer le message par rapport à l'expédteur du message, - Sécurté de la messagere Gérer les règles de fltrage de type stock défn par la parcelle Créer les règles de fltrage de message. Cec est équvalent, d'après l'équaton 3-2 à : s ( Sécurté de la messagere) = ( Sécurté de la messagere fltrage de message, Flux), ( Sécurté de la messagere gérer les règles de fltrage, Stock) Le len entre chaque îlot ssu de la scsson respecte la Règle d'urbansme Flux et stock. Le nouvel îlot fonctonnel Sécurté de la messagere Fltrage de message dépend donc de l'îlot fonctonnel Sécurté de la messagere Gérer les règles de fltrage. La dépendance de ces deux îlots fonctonnels est représentée Fgure 29. Dans ce dagramme de classes UML, le type d'un îlot est nséré dans le stéréotype de la classe UML de l'îlot. Par exemple, le stéréotype de l'îlot fonctonnel Sécurté de la messagere Fltrage de message est "îlot fonctonnel flux". Fgure 29 : Illustraton de la scsson d'un îlot fonctonnel respectant la contrante par typage des îlots Transformaton des voes du PLU fonctonnel contrante par le typage des îlots La sous-actvté de transformaton des voes du PLU fonctonnel sute au typage des îlots fonctonnels est la seconde parte de l'actvté de concepton automatsée des îlots et des voes fonctonnels entourée dans la Fgure

51 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Fgure 30 : Sous-actvté de transformaton des voes fonctonnelles par typage dans la démarche DA4EA Lors d'une scsson d'îlot fonctonnel, la règle d'urbansme suvante permet de transformer les voes ayant pour source ou pour cble l'îlot scndé. Règle d'urbansme Scsson îlot mult-typé n 5 Lors de la scsson d'un îlot fonctonnel : - toutes dépendances ayant pour source l'îlot fonctonnel scndé a pour source les îlots fonctonnels ssus de la scsson ; - toutes dépendances ayant pour cble l'îlot fonctonnel scndé a pour source les îlots fonctonnels ssus de la scsson. Dans le dagramme de classes de la Fgure 3, la dépendance avec l'îlot fonctonnel Récepton d'un message est transformée en : - une dépendance de l'îlot fonctonnel Sécurté de la messagere Fltrage de message de type flux vers l'îlot fonctonnel Récepton d'un message de type flux qu satsfat la Règle d'urbansme Flux et stock. La dépendance de l'îlot fonctonnel Sécurté de la messagere Gérer les règles de fltrage de type stock vers l'îlot fonctonnel Récepton d'un message de type flux ne peut être créée conformément à la Règle d'urbansme Scsson îlot mult-typé car elle ne respecte pas la Règle d'urbansme Flux et stock. Il est ntéressant de noter que l'absence de report de cette voe dans le modèle d'îlots fonctonnels a un sens méter. La geston des règles de fltrage de message est en effet ndépendante de la récepton d'un message. 50

52 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Fgure 3 : Illustraton des îlots et des voes fonctonnels respectant la contrante par typage des îlots 5

53 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Le dagramme de séquence UML de la Fgure 32 représente un scénaro possble nstancant les dépendances entre les îlots ssus de la scsson de l'îlot fonctonnel Sécurté de la messagere. Fgure 32 : Illustraton d'un scénaro nstancant des îlots respectant la contrante par typage des îlots Une nteracton a pour source une nstance de l'îlot fonctonnel Sécurté de la messagere Fltrage de message et pour cble une nstance de l'îlot fonctonnel de Sécurté de la messagere Gérer les règles de fltrage pusque le fltrage d'un message dépend des règles de fltrage applcables. Une nteracton a de plus pour source une nstance de l'îlot fonctonnel Sécurté de la messagere Fltrage de message et pour cble une nstance de l'îlot fonctonnel Récepton d'un message pour exprmer la dépendance entre le fltrage d'un message et sa récepton. 52

54 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI 3.4 Algnement de la vue méter d'une entreprse et de la vue fonctonnelle d'un SI L'archtecture des îlots et des voes de la vue fonctonnelle étant stablsée par le typage des îlots, un ndcateur ntéressant pour l'urbanste fonctonnel est la cohérence de cette vue fonctonnelle par rapport à la vue méter. Cette cohérence reflète l'écart de la prse en compte de la stratége de l'entreprse entre ces deux vues. L'actvté d'algnement de la vue fonctonnelle du SI avec la vue méter de l'entreprse ans que son évaluaton est entourée dans la Fgure 33. Fgure 33 : Actvté de mesure de l'algnement avec la vue méter dans la démarche DA4EA 3.4. Défnton de l'algnement de la vue fonctonnelle avec la vue méter L'algnement d'une vue fonctonnelle avec une vue méter nécesste de défnr les crtères d'algnement. L'ntérêt du méta-modèle des vues du cadre de l'urbansme est de proposer des concepts décrvant chaque vue. Le crtère d'algnement consste à - assocer des concepts de la vue méter et des concepts de la vue fonctonnelle décrts respectvement dans le et dans le , - vérfer leur cohérence. De façon macroscopque, deux grandes assocatons entre concepts de la vue méter et de la vue fonctonnelle peuvent être étudées : - l'assocaton entre les données méter de la vue méter et les données logques de la vue fonctonnelle, - l'assocaton entre les actvtés méter de la vue méter et les parcelles fonctonnelles de la vue fonctonnelle. Le chox est c d'assocer les actvtés méter et les parcelles fonctonnelles. L'algnement entre les données méter et les données logques se dédut en effet de l'algnement entre les actvtés méter et les parcelles fonctonnelles pusque, par défnton, - une donnée méter est produte par une actvté méter, - une donnée logque est produte par une ou pluseurs parcelles fonctonnelles d'un même îlot. 53

55 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI L'assocaton entre une relaton de successon d'actvtés méter et une relaton de dépendance de parcelles fonctonnelles défnes par la Sémantque UML Approche dynamque et dagramme de séquence (cf. 2..5) est auss cblée par cet algnement. Ces deux types de relaton caractérsent l'approche dynamque. Défnton : - deux actvtés méter sont en relaton de successon s l'une d'entre elles succède temporellement à l'autre dans un dagramme d'actvtés UML représentant une procédure méter (par exemple dans la Fgure 34, la relaton de successon ssue de l'actvté méter Récepton d'un message vers l'actvté méter Fltrage applqué au message) ; - deux parcelles fonctonnelles sont en relaton de dépendance s toutes deux sont exclusvement du type requête ou du type réponse et s l'une d'entre elles succède à l'autre dans un dagramme de séquence UML représentant un scénaro. Une parcelle P succède à une parcelle P 2 s la lgne de ve cble de P 2 est la lgne de ve à l'orgne de P (par exemple dans la Fgure 32, la relaton de dépendance de la parcelle fonctonnelle Fltrer un message par rapport à l'expédteur du message vers la parcelle fonctonnelle Créer les règles de fltrage de message ou la relaton de dépendance de la parcelle fonctonnelle Fltrer un message par rapport à l'expédteur du message vers la parcelle fonctonnelle Recevor un message). Défnton : l'algnement de la vue fonctonnelle avec la vue méter est défn de la façon suvante, - une parcelle fonctonnelle est algnée avec la vue méter o s la parcelle fonctonnelle a un sens méter commun avec au mons une o actvté de la vue méter, et s chaque actvté méter algnée avec la parcelle a au mons une relaton de successon avec une des autres actvtés méter algnées avec la parcelle ; - une relaton de dépendance entre deux parcelles fonctonnelles P et P 2, telle que P dépend de P 2, est algnée avec la vue méter s'l exste dans la vue méter, o au mons une actvté méter A algnée avec P, o au mons une actvté méter A 2 algnée avec P 2, o telles que A succède à A 2. L'llustraton proposée cble l'algnement des parcelles fonctonnelles et de leurs relatons de dépendance décrtes respectvement dans la Fgure 3 et dans la Fgure 32 avec les actvtés méter et leurs relatons de successon décrtes dans la Fgure

56 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Fgure 34 : Illustraton d'une vue méter L'algnement est celu : - de la parcelle fonctonnelle Recevor un message o avec l'actvté méter Récepton d'un message, - des parcelles Fltrer un message par rapport à l'expédteur du message et Fltrer un message par rapport à l'objet du message o avec l'actvté méter Fltrage applqué au message, - de la relaton de dépendance de la parcelle fonctonnelle Fltrer un message par rapport à l'expédteur du message vs-à-vs de la parcelle fonctonnelle Recevor un message o avec la relaton de successon de l'actvté méter Récepton d'un message vers l'actvté méter Fltrage applqué au message La parcelle fonctonnelle Créer les règles de fltrage de message et la relaton de dépendance de la parcelle fonctonnelle Fltrer un message par rapport à l'expédteur du message vs-à-vs de la parcelle fonctonnelle Créer les règles de fltrage de message ne sont pas algnées avec la vue méter. Aucune actvté du dagramme de la Fgure 34 n'a en effet de sens méter commun avec la parcelle de geston des règles de fltrage Axomatsaton de l'algnement de la vue fonctonnelle avec la vue méter Le comportement attendu de l'algnement des vues méter et fonctonnelle a pour paramètres les concepts défnssant cet algnement (cf. 3.4.). Une axomatsaton permet de décrre ce comportement attendu [Shepperd, 993]. La mesure chose pour évaluer cet algnement dot donc vérfer des axomes. L'algnement des vues méter et fonctonnelle est sot l'algnement de la vue fonctonnelle avec la vue méter sot l'algnement de la vue méter avec la vue fonctonnelle. Pour l'urbanste fonctonnel, la concepton de la vue fonctonnelle nécesste d'étuder le premer algnement. 55

57 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Les quatre axomes suvants décrvent l'algnement de la vue Fonctonnelle par rapport à la vue Méter (AFM). Ils cblent les concepts de la vue fonctonnelle défnssant l'algnement. AFM Ajout d'une nouvelle parcelle dans la vue fonctonnelle : l'algnement résultant de l'ajout d'une nouvelle parcelle dans la vue fonctonnelle est, par rapport à l'algnement précédent, - mons bon ou dentque s la parcelle n'a pas de sens méter commun avec au mons une actvté de la vue méter, - melleur ou dentque s la parcelle a un sens méter commun avec au mons une actvté de la vue méter. AFM2 Ajout d'une relaton de dépendance entre deux parcelles fonctonnelles : l'algnement résultant de l'ajout d'une relaton de dépendance entre deux parcelles fonctonnelles est, par rapport à l'algnement précédent, - mons bon ou dentque s'l n'exste pas de relaton de successon entre deux actvtés de la vue méter algnée avec la relaton de dépendance ajoutée, - melleur ou dentque s'l exste au mons une relaton de successon entre deux actvtés de la vue méter algnée avec la relaton de dépendance ajoutée AFM3 Suppresson d'une parcelle de la vue fonctonnelle : l'algnement résultant de la suppresson d'un îlot de la vue fonctonnelle est, par rapport à l'algnement précédent, - mons bon ou dentque s la parcelle a un sens méter commun avec au mons une actvté de la vue méter, - melleur ou dentque s la parcelle n'a pas de sens méter commun avec au mons une actvté de la vue méter. AFM4 Suppresson d'une relaton de dépendance entre deux parcelles fonctonnelles : l'algnement résultant de la suppresson d'une relaton de dépendance entre deux parcelles fonctonnelles est, par rapport à l'algnement précédent, - mons bon ou dentque s'l exste au mons une relaton de successon entre deux actvtés de la vue méter algnée avec la relaton de dépendance supprmée, - melleur ou dentque s'l n'exste pas de relaton de successon entre deux actvtés de la vue méter algnée avec la relaton de dépendance supprmée Mesure de l'algnement de la vue fonctonnelle avec la vue méter La mesure de l'algnement est un outl ms à la dsposton de l'urbanste fonctonnel afn de vérfer la cohérence de sa vue fonctonnelle par rapport à la vue méter de l'entreprse. Les axomes à vérfer sont les axomes AFM, AFM2, AFM3, AFM4 décrts dans le La mesure proposée est le produt du pourcentage de parcelles algnées par le pourcentage de relatons de dépendance entre parcelles algnées. Défnton : La mesure MAFM de l'algnement de la vue fonctonnelle VF par rapport à la vue méter conforme à l'axomatsaton est telle que : ( ) MAFM VF N = p ( VF ) Nnap( VF ) N ( VF ) p N r ( VF ) N ( ) ( ) nar VF Nr VF Équaton 3-3 avec pour paramètres, - le nombre N p (VF) de parcelles de la vue fonctonnelle VF, - le nombre N nap (VF) de parcelles de la vue fonctonnelle VF non algnées avec des actvtés de la vue méter, - le nombre N r (VF) de relatons de dépendance entre parcelles de la vue fonctonnelle VF, - le nombre N nar (VF) de relatons de dépendance entre parcelles de la vue fonctonnelle VF non algnées avec des relatons de successon entre actvtés de la vue méter. 56

58 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI La mesure MAFM prend toutes ses valeurs dans l'ntervalle [0, ]. MAFM vaut 0 lorsqu'aucune parcelle de la vue fonctonnelle ou aucune relaton de dépendance entre parcelles n'est algnée avec la vue méter. A l'opposé, MAFM vaut lorsque l'algnement est parfat, c'est-à-dre lorsque toutes les parcelles et leurs relatons de dépendance sont algnées avec la vue méter. Proposton : la mesure MAFM vérfe les quatre axomes AFM, AFM2, AFM3, AFM4 de l'algnement fonctonnel par rapport à la vue méter. Démonstraton : - AFM : Sot P une parcelle fonctonnelle ajoutée à la vue fonctonnelle VF, d'après l'équaton 3-3, N p ( VF { P} ) N nap ( VF { P} ) { } ( { }) N r VF P N nar VF MAFM VF P = ( { }) N p VF P N r ( VF { P} ) ( N p ( VF ) + ) N nap ( VF ) + N nap ({ P} ) N ( VF ) + ( ) ( VF ) N nar ( VF ) ( ) N r VF ( ) ( { P} ) N r p pusque le nombre de relatons de dépendance entre parcelles n'est pas modfé. MAFM VF P MAFM VF = N N N p o nap nap ( VF ) ( VF ) ( { }) ( ) ( VF ) + N nap ({ P} ) N ( VF ) + p ( VF ) + N nap ({ P} ) N ( VF ) + N N nap p ( VF ) ( VF ) N * ( VF ) N nar ( VF ) ( ) N r VF ( VF ) N nar ( VF ) N ( VF ) N nap N r * p S la parcelle n'a pas de sens méter commun avec au mons une actvté P = de la vue méter alors N nap ({ }) MAFM ( VF { P} ) MAFM ( VF ) = N nap ( VF ) N nap ( VF ) + N ( VF ) N ( VF ) ( ) ( ) ( ) r nar * N p VF N p VF + N r VF Or, N nap ( VF ) N nap ( VF ) + N nap ( VF ) N p ( VF ) = N p ( VF ) N p ( VF ) + N p ( VF ) ( N p ( VF ) + ) MAFM ( VF { P} ) MAFM ( VF ) 0 pusque le nombre de parcelles non algnées est nféreur ou égal au nombre total de parcelles. Il y a égalté des mesures d'algnement lorsque N ( VF ) N ( VF ) p = nap c'est-à-dre, lorsqu'aucune parcelle de le vue fonctonnelle VF est algnée avec la vue méter. r r = = 57

59 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI o S la parcelle a un sens méter commun avec au mons une actvté de la vue méter alors N nap ({ P} ) = 0 MAFM ( VF { P} ) MAFM ( VF ) = N nap ( VF ) N nap ( VF ) N ( VF ) N ( VF ) ( ) ( ) ( ) r nar * N p VF N p VF + N r VF N nap ( VF ) N ( VF ) N ( VF ) Or, N ( VF ) nap nap = p N p ( VF ) + N p ( VF ) ( N p ( VF ) + ) 0 MAFM ( VF { P} ) MAFM ( VF ) Il y a égalté des mesures d'algnement lorsque ( VF ) = 0 N nap, c'est-à-dre lorsque toutes les parcelles de le vue fonctonnelle VF sont algnées avec la vue méter. - AFM2 est vérfé de la même façon par la mesure MAFM pusque N r (VF) et N p (VF) d'un côté, N nar (VF) et N nap (VF) ont un rôle symétrque dans l'équaton AFM3 : Sot P une parcelle fonctonnelle supprmée de la vue fonctonnelle VF, d'après l'équaton 3-3, N p ( VF { P} ) N nap ( VF { P} ) ( { }) ( { }) ( { }) N r VF P N nar VF P P = ( { }) N p VF P N r ( VF { P} ) ( N p ( VF ) ) ( N nap ( VF ) N nap ({ P} )) N ( VF ) N ( VF ) ( ) ( ) r nar N VF p N r VF MAFM VF pusque le nombre de relatons de dépendance entre parcelles n'est pas modfé. MAFM VF N N N nap p o nap ( VF ) ( VF ) ( { P} ) MAFM ( VF ) ( VF ) N nap ({ P} ) N ( VF ) p N nap ( VF ) N nap ({ P} ) N ( VF ) p = N N nap p N * ( VF ) ( VF ) r N * ( VF ) N nar ( VF ) ( ) N r VF r ( VF ) N nar ( VF ) N ( VF ) S la parcelle n'a pas de sens méter commun avec au mons une actvté de la vue méter alors N nap ({ P} ) = MAFM ( VF { P} ) MAFM ( VF ) = N nap ( VF ) N nap ( VF ) N ( VF ) N ( VF ) ( ) ( ) ( ) r nar * N p VF N p VF N r VF N nap ( VF ) N nap ( VF ) N p ( VF ) N nap ( VF ) = Or N p ( VF ) N p ( VF ) N p ( VF ) N p ( VF ) + MAFM ( VF { P} ) MAFM ( VF ) 0 ( ) pusque le nombre de parcelles non algnées est nféreur ou égal au nombre total de parcelles. Il y a égalté des mesures d'algnement lorsque N p ( VF ) = N nap ( VF ), c'està-dre lorsqu'aucune parcelle de le vue fonctonnelle VF est algnée avec la vue méter. r = = 58

60 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI o S la parcelle a un sens méter commun avec au mons une actvté de la vue méter alors N nap ({ P} ) = 0 MAFM ( VF { P} ) MAFM ( VF ) = N nap ( VF ) N nap ( VF ) N ( VF ) N ( VF ) ( ) ( ) ( ) r nar * N p VF N p VF N r VF N nap ( VF ) N ( VF ) N ( VF ) Or N ( VF ) nap nap = p N p ( VF ) N p ( VF ) ( N p ( VF ) ) 0 MAFM ( VF { P} ) MAFM ( VF ) Il y a égalté des mesures d'algnement lorsque ( VF ) = 0 N nap, c'est-à-dre lorsque toutes les parcelles de le vue fonctonnelle VF sont algnées avec la vue méter. - AFM4 est vérfé de la même façon par la mesure MAFM pusque N r (VF) et N p (VF) d'un côté, N nar (VF) et N nap (VF) ont un rôle symétrque dans l'équaton 3-3. Dans l'llustraton chose de l'algnement de la vue fonctonnelle VF, représentée respectvement pour les parcelles dans la Fgure 3 et pour les relatons de dépendance entre parcelles dans la Fgure 32, avec la vue méter, représentée Fgure 34 : - N p ( VF ) = 4, - ( VF ) = N nap pusque la parcelle Créer les règles de fltrage de message de la Fgure 3 ne peut être algnée avec la vue méter, N r VF =, - ( ) 2 - ( VF ) = N nar pusque la relaton de dépendance de la parcelle Fltrer un message par rapport à l'expédteur du message vers la parcelle Créer les règles de fltrage de message de la Fgure 32 ne peut être algnée avec la vue méter. La mesure MAFM de l'algnement de la vue fonctonnelle VF par rapport à la vue méter conforme à l'axomatsaton est alors : MAFM ( VF ) 4 = 4 2 = 2 75% des parcelles et 50% des relatons de dépendance entre parcelles sont en effet algnées avec la vue méter. La mesure pourrat être amélorée par l'urbanste fonctonnel en estmant que la geston des règles de fltrage d'un message ne fat pas parte de la vue fonctonnelle du SI. L'urbanste dot alors vérfer ce chox avec la stratége de l'entreprse

61 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI 3.5 Concepton automatsée des quarters du PLU fonctonnel Les îlots et les voes d'une même zone de la vue fonctonnelle ans stablsés par le typage des parcelles de chaque îlot et par la mesure de l'algnement de la vue fonctonnelle avec la vue méter peuvent alors être regroupés dans des quarters. Chaque urbanste fonctonnel conçot les quarters fonctonnels de la zone dont l est responsable lors de l'actvté entourée dans la Fgure 35. Fgure 35 : Actvté de concepton automatsée des quarters dans la démarche DA4EA La méthode de concepton des quarters proposée dans ce paragraphe a pour objectf d'assster l'urbanste fonctonnel par une méthode automatsée fondée sur une approche dynamque de la concepton des îlots de la vue fonctonnelle Approche dynamque de la concepton des quarters L'actvté de concepton des quarters fonctonnels a pour objectf de regrouper dans un quarter des îlots fonctonnels dont le couplage est sgnfcatf. La mesure du couplage de deux îlots fonctonnels nécesste une approche dynamque. Elle s'appue en effet sur la transformaton d'un ensemble de séquences d'nstances d'îlots fonctonnels spécfques à la zone étudée en un ensemble de regroupements dsjonts d'îlots pouvant former des quarters. Les séquences d'nstances d'îlots fonctonnels représentent des scénaros de cas d'utlsaton propres à la zone étudée par l'urbanste fonctonnel. Les nteractons entre les îlots fonctonnels nstancés dans ces séquences détermnent un couplage entre les îlots fonctonnels. Cette déducton est due à la conformté des nteractons entre nstances d'îlots fonctonnels avec les voes fonctonnelles entre ces îlots (cf. Règle d'urbansme Interactons et voes du 3.2). Le prncpe est de ler le couplage entre deux îlots avec le nombre d'nteractons entre des nstances des ces îlots durant les scénaros de cas d'utlsaton propres à la zone. 60

62 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Le couplage entre îlots fonctonnels est représenté sur le dagramme de séquence UML de la Fgure 36. Chaque nteracton de type requête entre nstances d'îlots fonctonnels est un paramètre du couplage entre les îlots nstancés. Paramètre du couplage entre les îlots fonctonnels Sécurté de la messagere Fltrage de message et Sécurté de la messagere Gérer les règles de fltrage Paramètre du couplage entre les îlots fonctonnels Sécurté de la messagere Fltrage de message et Récepton d'un message Fgure 36 : Illustraton du couplage entre îlots fonctonnels à partr d'une approche dynamque de la vue fonctonnelle des îlots Ce scénaro augmente donc le couplage : - entre les îlots fonctonnels Sécurté de la messagere Fltrage de message et Sécurté de la messagere Gérer les règles de fltrage, - entre les îlots fonctonnels Sécurté de la messagere Fltrage de message et Récepton d'un message. 6

63 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Pertnence d'un regroupement d'îlots fonctonnels dans une même entté fonctonnelle Afn de mesurer le couplage d'un ensemble d'îlots fonctonnels, un ndcateur de pertnence de cet ensemble est proposé [INPI 05929] [INPI 0647]. Défnton : Une entté fonctonnelle est un regroupement d'îlots fonctonnels. Un quarter fonctonnel est une entté fonctonnelle partculère où les îlots regroupés ont un couplage sgnfcatf. Afn de proposer une mesure de la pertnence d'un regroupement d'îlots fonctonnels, des axomes du comportement de cette pertnence du regroupement d'îlots sont défns. Les concepts à prendre en compte sont ceux d'îlot fonctonnel et de relaton de dépendance entre îlots fonctonnels. Défnton : Deux îlots fonctonnels sont en relaton de dépendance s'l exste une nteracton de type requête de l'un vers l'autre dans un dagramme de séquence UML. L'îlot à l'orgne de l'nteracton dépend de l'îlot à la cble de cette nteracton. C'est le cas dans la Fgure 32 de la relaton de dépendance de l'îlot fonctonnel Sécurté de la messagere Fltrage de message vs-à-vs de l'îlot fonctonnel Sécurté de la messagere Gérer les règles de fltrage ou de la relaton de dépendance de l'îlot fonctonnel Sécurté de la messagere Fltrage de message vs-à-vs de l'îlot fonctonnel Récepton d'un message. Les axomes suvants caractérsent la Pertnence du Regroupement d'îlots fonctonnels (PRI) dans une même entté fonctonnelle. Ils sont fondés sur le fat que la pertnence est assmlée à la longueur moyenne des séquences nternes à l'entté fonctonnelle regroupant des îlots fonctonnels. Une séquence nterne à une entté fonctonnelle est une séquence, sans nterrupton, de relatons de dépendance entre îlots de l'entté fonctonnelle. PRI Ajout d'un îlot fonctonnel dans l'entté fonctonnelle : la pertnence d'une entté fonctonnelle résultante de l'ajout d'un îlot fonctonnel dans l'entté fonctonnelle est, par rapport à la pertnence précédente, - dentque s'l n'y a pas de relaton de dépendance entre l'îlot ajouté et les autres îlots de l'entté fonctonnelle, - melleure s'l y a au mons une relaton de dépendance entre l'îlot ajouté et les autres îlots de l'entté fonctonnelle. PRI2 Ajout d'une nouvelle relaton de dépendance entre îlots fonctonnels : la pertnence d'une entté fonctonnelle résultante de l'ajout d'une nouvelle relaton de dépendance entre îlots fonctonnels est, par rapport à la pertnence précédente, - dentque s la relaton de dépendance est entre deux îlots fonctonnels dont au mons un n'appartent pas à l'entté fonctonnelle, - melleure s la relaton de dépendance est entre deux îlots fonctonnels appartenant à l'entté fonctonnelle. PRI3 Suppresson d'un îlot fonctonnel de l'entté fonctonnelle : la pertnence d'une entté fonctonnelle résultante de la suppresson d'un îlot fonctonnel de l'entté fonctonnelle est, par rapport à la pertnence précédente, - mons bonne s'l y a au mons une relaton de dépendance entre l'îlot supprmé et un autre îlot de l'entté fonctonnelle, - dentque s'l n'y a pas de relaton de dépendance entre l'îlot supprmé et un autre îlot de l'entté fonctonnelle. 62

64 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI PRI4 Suppresson d'une relaton de dépendance entre îlots fonctonnels : la pertnence d'une entté fonctonnelle résultante de la suppresson d'une nouvelle relaton de dépendance entre îlots fonctonnels est, par rapport à la pertnence précédente, - mons bonne s la relaton de dépendance est entre deux îlots fonctonnels appartenant à l'entté fonctonnelle. - dentque s la relaton de dépendance est entre deux îlots fonctonnels dont au mons un n'appartent pas à l'entté fonctonnelle. La mesure de la pertnence d'un regroupement d'îlots fonctonnels dans une entté fonctonnelle E est un outl ms à la dsposton de l'urbanste fonctonnel afn de l'assster dans la concepton des quarters fonctonnels d'une zone du PLU fonctonnel. Les axomes à vérfer sont les axomes PRI, PRI2, PRI3, PRI4. La mesure proposée est la longueur moyenne, en termes de relatons de dépendance entre îlots fonctonnels, des séquences nternes à l'entté fonctonnelle E. Défnton : La mesure MPRI de la pertnence d'un regroupement d'îlots fonctonnels dans une même entté fonctonnelle E à partr d'un ensemble Se de séquences d'nstances d'îlot fonctonnel réalsées par un ensemble Sc de scénaros est telle que : MPRI ( E, Sc, Se) = 2 ( ) N ( E, Se) N ( E, Se) Équaton 3-4 avec : - N (E, Se), le nombre de séquences de nstances d'îlots fonctonnels appartenant à E extrates de Se. MPRI vaut 0 s'l n'exste aucune séquence de Se contenant strctement plus d'une nstance d'îlot fonctonnel de E. Remarque : l'ensemble Se et l'ensemble Sc sont dfférents car l'nstance du cas d'utlsaton représentant le scénaro n'est pas une nstance d'îlot fonctonnel. Les séquences d'nstances d'îlots fonctonnels de Se prses en compte dans le calcul de l'ndcateur de pertnence d'une entté fonctonnelle sont les séquences nternes à l'entté fonctonnelle de longueur maxmale. La noton de "séquence nterne à l'entté fonctonnelle de longueur maxmale" sgnfe que s E = {C, C2, C3} et s'l exste dans une séquence de Se, l'enchaînement d'nteractons C C2 C3, alors les enchaînements d'nteractons ncluses C C2 et C2 C3 ne seraent pas à prendre en compte pour le calcul de MPRI(E, Sc, Se). S l(s) est la longueur d'une séquence s de Se, en termes de relatons de dépendances, la mesure MPRI prend toutes ses valeurs dans l'ntervalle l s Se, Card ( s) 0. ( ) Se MPRI vaut 0 lorsqu'aucune relaton de dépendance entre îlots fonctonnels n'exste dans Se. MPRI vaut séquences de Se. s Se l Card ( s) ( Se) lorsque E content tous les îlots fonctonnels nstancés dans les 63

65 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Proposton : la mesure MPRI vérfe les quatre axomes PRI, PRI2, PRI3, PRI4 de la pertnence d'un regroupement d'îlots fonctonnels dans une même entté fonctonnelle. Démonstraton : - PRI : Sot I un îlot fonctonnel ajouté dans l'entté fonctonnelle E, d'après l'équaton 3-4, ( ) N( E { I}, Se) 2 MPRI ( E { I}, Sc, Se) = N ( E I, Se) { } o S l'îlot ajouté n'a pas de relaton de dépendance avec les autres îlots de E, alors, N ( E I, Se) N ( E, Se o MPRI { } ) = ( ) N ( E, Se) 2 ( E { I}, Sc, Se) = = MPRI ( E, Sc, Se) N ( E, Se) S l'îlot ajouté a une relaton de dépendance avec un autre îlot de E et s cette relaton de dépendance est ntégrée à une séquence de j îlots fonctonnels de Se, alors, j, j + N ( E I, Se) N ( E, Se avec N ( E I, Se) = N ( E, Se) j { } { } ) = j j + ( j + Se + et N E { I}, Se) = N ( E, ) pusqu'une séquence de j îlots est remplacée par une séquence de j + îlots. MPRI E I, Sc, Se = 2 2, j, j+ Or, ( { } ) ( ) N ( E, Se) +, j, j + N ( E, Se ( ) N ( E, Se) + 2 MPRI ( j ) ( N j ( E, Se) ) + ( j ( N j + ( E, Se) + ) ) + ( N ( E, Se) ) + ( N ( E, Se) + ) (( j ) ( ) ) + ( j ( + ) ) N ( E, Se) ( ) N( E, Se) + > N ( E, Se) ( E { I}, Sc, Se) > MPRI ( E, Sc, Se) j 2 N ( E, Se) j + = ( ) N ( E, Se) 2 ( ) N ( E, Se) + N ( E, Se) Conformément à la démonstraton pour une séquence, l'négalté est démontrée par récurrence de façon mmédate pour l'ntégraton de la relaton de dépendance dans n séquences de Se. = 64

66 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI - PRI2 : Sot R une relaton de dépendance entre îlots fonctonnels ajouté à l'ensemble des séquences Se, d'après l'équaton 3-4, ( ) N ( E, Se { R} ) 2 MPRI ( E, Sc, Se { R} ) = N ( E, Se R ) La démonstraton est dentque à celle pour l'axome PRI pusque : o l'hypothèse que la relaton de dépendance ajoutée ne sot pas nterne à l'entté fonctonnelle est équvalente au cas où un îlot n'ayant pas de relaton de dépendance avec un autre îlot de l'entté fonctonnelle est ajouté à celle-c, o l'hypothèse que la relaton de dépendance ajoutée sot nterne à l'entté fonctonnelle est équvalente au cas où un îlot ayant une relaton de dépendance avec un autre îlot de l'entté fonctonnelle est ajouté à celle-c. - PRI3 : Sot I un îlot fonctonnel supprmé de l'entté fonctonnelle E, d'après l'équaton 3-4, ( ) N ( E { I}, Se) 2 MPRI ( E { I}, Sc, Se) = N ( E I, Se) o { } { } S l'îlot supprmé a une relaton de dépendance avec un autre îlot de E et s cette relaton de dépendance est ntégrée à une séquence de j îlots fonctonnels de Se, alors, j, j N ( E I, Se) N ( E, Se { } ) = avec N ( E { I}, Se) = N j ( E, Se) + N ( E { I}, Se) = N ( E, Se) j j et j pusqu'une séquence de j îlots est remplacée par une séquence de j îlots. MPRI E I, Sc, Se = 2 2, j, j Or, ( { } ) ( ) N ( E, Se) +, j, j N ( E, ( ) N ( E, Se) + 2 MPRI ( j 2) ( N j ( E, Se) + ) + ( j ) ( N j ( E, Se) ) Se) + ( N ( E, Se) ) + ( N ( E, Se) + ) j (( j 2) ( + ) ) + (( j ) ( ) ) N ( E, Se) ( ) N( E, Se) < N ( E, Se) 2 ( ) N ( E, Se) N ( E, Se) ( E { I}, Sc, Se) < MPRI ( E, Sc, Se) j = 2 ( ) N ( E, Se) N ( E, Se) Conformément à la démonstraton pour une séquence, l'négalté est démontrée par récurrence de façon mmédate pour l'ntégraton de la relaton de dépendance dans n séquences de Se. o S l'îlot ajouté n'a pas de relaton de dépendance avec les autres îlots de E, alors, N ( E I, Se) N ( E, Se MPRI { } ) = ( ) N ( E, Se) 2 ( E { I}, Sc, Se) = = MPRI ( E, Sc, Se) N ( E, Se) = 65

67 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI - PRI4 : Sot R une relaton de dépendance entre îlots fonctonnels ajouté à l'ensemble des séquences Se, d'après l'équaton 3-4, ( ) N( E, Se { R} ) 2 MPRI ( E, Sc, Se { R} ) = N ( E, Se R ) { } La démonstraton est dentque à celle pour l'axome PRI3 pusque : o l'hypothèse que la relaton de dépendance supprmée sot nterne à l'entté fonctonnelle est équvalente au cas où un îlot ayant une relaton de dépendance avec un autre îlot de l'entté fonctonnelle est supprmé de celle-c, o l'hypothèse que la relaton de dépendance supprmée ne sot pas nterne à l'entté fonctonnelle est équvalente au cas où un îlot n'ayant pas de relaton de dépendance avec un autre îlot de l'entté fonctonnelle est supprmé de celle-c. 66

68 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Dans l'llustraton chose de la vue fonctonnelle avec les îlots représentés dans la Fgure 3 et les séquences de Se représentées dans la Fgure 32, quatre enttés fonctonnelles sont envsageables : Sécurté de la messagere - Fltrage de message, - E = Sécurté de la messagere - Gérer les règles de fltrage N E, Se pour l'îlot cble de l'nteracton Recevor un message de type ( ) = réponse, et N ( E, Se) pour les tros nstances d'îlots partcpantes à l'enchaînement des 3 = nteractons Créer les règles de fltrage de message de type requête et Créer les règles de fltrage de message de type réponse. ( ) N ( E, Se) 2 ( ) ( 0) + ( 2 ) 2 MPRI E, Sc, Se = = = = N ( E, Se) E = { Sécurté de la messagere - Fltrage de message, Récepton d' un message} ( E, Se) N pour l'îlot source de l'nteracton Créer les règles de fltrage de = type requête, et N ( E, Se) pour les tros nstances d'îlots partcpantes à l'enchaînement des 3 = nteractons Recevor un message de type requête et Recevor un message de type réponse. ( ) N ( E, Se) 2 ( ) ( 0) + ( 2 *) 2 MPRI E, Sc, Se = = = = N ( E, Se) E = { Sécurté de la messagere - Gérer les règles de fltrage, Récepton d' un message} ( E, Se) 2 - N pour l'nstance d'îlot cblée par l'nteracton Créer les règles de = fltrage de message de type requête et l'nstance d'îlot cblée par l'nteracton Recevor un message de type requête ( ) N ( E, Se) 2 MPRI ( E, Sc, Se) = = 0 N ( E, Se) Sécurté de la messagere - Fltrage de message, E = Sécurté de la messagere E, Se ( ) 5 = - Gérer les règles de fltrage, Récepton d' un message N pour les cnq nstances d'îlots partcpantes à l'enchaînement des nteractons Créer les règles de fltrage de message de type requête et Créer les règles de fltrage de message de type réponse, Recevor un message de type requête et Recevor un message de type réponse. ( ) N( E, Se) 2 ( ) ( 0) + ( 2 0) + ( 3 0) + ( 4 *) MPRI E, Sc, Se = = = 4 N ( E, Se) Parm toutes ces enttés fonctonnelles, seule E = Sécurté de la messagere - Gérer les règles de fltrage, Récepton d' un message a une { } pertnence de regroupement de ses îlots fonctonnels nulle, pusqu'l n'exste pas de relaton de dépendance entre ces îlots dans Se. 67

69 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Seul d'nserton d'un îlot fonctonnel dans une entté fonctonnelle Le résultat de la concepton des quarters est alors celu de l'analyse de toutes les enttés fonctonnelles possbles de pertnence non nulle. Afn de faclter l'analyse, un seul d'nserton d'un îlot fonctonnel dans une entté fonctonnelle est proposé [INPI 05929] [INPI 0647]. S la pertnence résultante de l'nserton d'un îlot dans une entté fonctonnelle est supéreure au seul d'nserton de l'îlot dans cette entté fonctonnelle, alors l'entté fonctonnelle résultante de l'nserton est un quarter fonctonnel potentel. Snon, l'entté fonctonnelle n'est pas un quarter fonctonnel potentel. Le seul d'nserton d'un îlot fonctonnel dans une entté fonctonnelle est fondé sur un nombre mnmum d'nteractons entre un îlot fonctonnel de chaque séquence de îlots fonctonnels de E et l'îlot fonctonnel nséré I. Ce nombre mnmum d'nteractons est calculé à partr du nombre de scénaros où apparassent des séquences de îlots fonctonnels de E et du nombre de scénaros où apparaît I. L'évaluaton du seul d'nserton d'un îlot fonctonnel dans une entté fonctonnelle est un outl ms à la dsposton de l'urbanste fonctonnel afn d'optmser la concepton des quarters fonctonnels d'une zone du PLU fonctonnel. Défnton : La mesure MSIE du seul d'nserton d'un îlot fonctonnel I dans une entté fonctonnelle E à partr d'un ensemble Se de séquences d'nstances d'îlot fonctonnel réalsées par un ensemble Sc de scénaros est telle que : MSIE ( E, I, Sc, Se) N = N ({ I}, Sc) ({ I}, Se) ( N ( E, Sc) ) N ( E, Se) Équaton ( ) N ( N ( E, Se) N ( E, Sc) ) ({ I}, Se) N (, ) E Se avec : - Se, l'ensemble des séquences d'lots nstancés lors du déroulement de scénaros de cas d'utlsaton du système, - Sc, l'ensemble des scénaros de cas d'utlsaton du système, - N (E, Se), le nombre de séquences de nstances d'îlots fonctonnels appartenant à E extrates de Se, - N (E, Sc), le nombre de scénaros dstncts comportant une séquence de nstances d'îlots fonctonnels appartenant à E extrates Sc. De la même façon que pour la pertnence du regroupement d'îlots fonctonnels dans une même entté fonctonnelle, les séquences d'nstances d'îlots fonctonnels prses en compte dans le calcul de MSIE sont les séquences nternes à l'entté fonctonnelle de longueur maxmale. 68

70 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Dans l'llustraton chose de la vue fonctonnelle avec les îlots représentés dans la Fgure 3 et les séquences de Se du seul scénaro de Sc représenté dans la Fgure 32, quatre nsertons d'îlot fonctonnel dans une entté fonctonnelle sont envsageables (seule est écartée l'entté fonctonnelle résultante de l'nserton dont la pertnence est nulle dans l'llustraton du 3.5.2) : E = Sécurté de la messagere - Fltrage de message et - Soent { } I = Sécurté de la messagere - Gérer les règles de fltrage N ({ I}, Sc) = et N ({ I}, Se) = N E, Sc et N ( E, Se) 3 ( ) = Fltrage de message. MSIE N N N N ({ I}, Sc) ({ I}, Se) ({ I}, Sc) ({ I}, Se) ( E, I, Se, Sc) N N = = ( N ( E, Sc) ) N ( E, Se) ( E, Sc) = = ( E, Se) 3 3 pour les nstances de l'îlot I, et, pour les nstances de l'îlot Sécurté de la messagere + 2 ( ) N ( N ( E, Se) N ( E, Sc) ) ({ I}, Se) N ( E, Se) = Remarque : Le seul est dentque pour E = Sécurté de la messagere - Gérer les règles de fltrage et { } I = Sécurté de la messagere - Fltrage de message. La pertnence de E { I} évaluée dans le est MPRI ( E { I}, Sc, Se) = > = MSIE( E, I, Se, Sc) l'entté fonctonnelle 3 E { I} est mémorsée comme un quarter fonctonnel potentel. - Soent = { Sécurté de la messagere - Fltrage de message} I = Récepton d' un message N ({ I}, Sc) = et N { I}, Se N E, Sc et N ( E, Se) 3 ( ) = Fltrage de message. MSIE N N ({ I}, Sc) ({ I}, Se) ( E, I, Se, Sc) E et ( ) = = = ( N ( E, Sc) ) N ( E, Se) pour les nstances de l'îlot I, et, pour les nstances de l'îlot Sécurté de la messagere + 2 ( ) ( N ( E, Se) N ( E, Sc) ) ({ I}, Se) N( { I}, Sc) N( E, Sc) = = N( { I}, Se) N( E, Se) 3 3 Remarque : Le seul est dentque pour = { Récepton d' un message} N N ( E, Se) = E et I = Sécurté de la messagere - Fltrage de message. La pertnence de E { I} évaluée dans le est MPRI ( E { I}, Sc, Se) = > = MSIE( E, I, Se, Sc) l'entté fonctonnelle 3 E { I} est mémorsée comme un quarter fonctonnel potentel. 69

71 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Sécurté de la messagere - Fltrage de message, = Sécurté de la messagere - Gérer les règles de fltrage I = Récepton d' un message N ({ I}, Sc) = et N ({ I}, Se) = pour les nstances de l'îlot I, et, N E, Sc et N ( E, Se) ans que ( E, Sc) N E, Se - Soent ( ) = E et = N et ( ) 3 = 3 = pour les nstances des îlots fonctonnels Sécurté de la messagere Fltrage de message et Sécurté de la messagere Gérer les règles de fltrage. MSIE N N ({ I}, Sc) ({ I}, Se) ( E, I, Se, Sc) = ( N ( E, Sc) ) N ( E, Se) + 2 ( ) ( N ( E, Se) N ( E, Sc) ) ({ I}, Se) ( ) + ( 2 0) + ( 3 ) 2 ( ) + = ( ) La pertnence de { I} MPRI ( E { I}, Sc, Se) = 4 > 2 = MSIE( E, I, Se, Sc) l'entté fonctonnelle E { I} mémorsée comme un quarter fonctonnel potentel. N N ( E, Se) = E évaluée dans le est - Soent E = { Sécurté de la messagere - Fltrage de message, Récepton d' un message} et I = Sécurté de la messagere - Gérer les règles de fltrage N ({ I}, Sc) = et N ({ I}, Se) = N E, Sc et N ( E, Se) ans que ( E, Sc) ( ) = = pour les nstances de l'îlot I, et, N et N ( E, Se) 3 = 3 = est pour les nstances des îlots fonctonnels Sécurté de la messagere Fltrage de message et Récepton d'un message. MSIE N N ({ I}, Sc) ({ I}, Se) ( E, I, Se, Sc) = ( N ( E, Sc) ) N ( E, Se) + 2 ( ) ( N ( E, Se) N ( E, Sc) ) ({ I}, Se) ( ) + ( 2 0) + ( 3 ) 2 ( ) + = ( ) La pertnence de { I} MPRI ( E { I}, Sc, Se) = 4 > 2 = MSIE( E, I, Se, Sc) l'entté fonctonnelle E { I} mémorsée comme un quarter fonctonnel potentel. N N ( E, Se) = E évaluée dans le est est 70

72 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Algorthme bactérologque de concepton des quarters fonctonnels à partr des enttés fonctonnelles Un algorthme de concepton des quarters fonctonnels exste déjà à partr de la pertnence d'une entté fonctonnelle et du seul de regroupement d'enttés fonctonnelles [INPI 0647]. Le prncpe est de représenter le regroupement d'enttés fonctonnelles dans une structure arborescente. Chaque nœud de l'arbre est une entté fonctonnelle. Un arbre bnare d'enttés fonctonnelles est alors conçu à partr des melleurs regroupements d'enttés fonctonnelles. Les regroupements sont classés à partr du rapport entre la pertnence de l'entté fonctonnelle résultante du regroupement et le seul de regroupement des deux enttés fonctonnelles cbles du regroupement. La dffculté lors de cette concepton arborescente est d'évter les mnma locaux. En effet, lors d'une égalté des gans, un chox entre les regroupements d'enttés fonctonnelles ayant le même gan est réalsé de façon aléatore. Ce chox peut fare dsparaître dans la sute de l'algorthme des enttés fonctonnelles pertnentes. Afn d'évter les mnma locaux, une soluton est d'utlser un algorthme génétque [Goldberg, 989]. En nformatque, l'algorthmque génétque permet, par exemple, de regrouper des composants d'un système afn d'optmser leur confguraton [Zhang, 2000]. Dans le cas de regroupement d'îlots, les enttés fonctonnelles forment en effet une populaton qu évolue du fat d'nsertons successves d'îlots dans une entté ou de suppresson d'îlots dans une entté. L'nserton d'un îlot fonctonnel dans une entté fonctonnelle est synonyme d'une mutaton d'un élément de la populaton. Au cours de ces mutatons successves, une sélecton des melleures enttés fonctonnelles permet de concevor les quarters fonctonnels. Le beson de l'urbanste fonctonnel est d'obtenr une lste de quarters fonctonnels potentels afn de chosr parm ceux-c les plus pertnents quant au PLU fonctonnel cble. Son chox d'expert fonctonnel du SI peut être dfférent de celu de l'ensemble de quarters fonctonnels dsjonts recouvrant sa zone et possédant la pertnence la plus élevée (cf ). Une soluton est de mémorser les melleurs regroupements et de supprmer les plus fables. C'est la rason pour laquelle, la concepton des quarters fonctonnels est supportée par une approche bactérologque. Cette approche fondée sur le comportement des bactéres a été mse en œuvre pour l'automatsaton des tests de logcel [Baudry, 2005]. Le prncpe retenu est de défnr une bactére par une entté fonctonnelle, sot un regroupement d'îlots fonctonnels. La qualté d'une bactére est corrélée au couplage des îlots fonctonnels qu la consttuent lors du déroulement de scénaros de cas d'utlsaton de la zone fonctonnelle : - une bactére est d'autant melleure que le couplage entre ses îlots fonctonnels est fort, - une mauvase bactére est une bactére où les îlots fonctonnels ont un couplage nul. Les crtères de qualté des bactéres sont défns par des fonctons bactérologques [Baudry2, 2005] adaptées au regroupement d'îlots fonctonnels Fonctons bactérologques S Λ est l'ensemble des enttés fonctonnelles regroupant un ou pluseurs îlots fonctonnels, la foncton d'utlté F d'un ensemble d'enttés fonctonnelles E, telles que, E Λ, permet d'évaluer la qualté de cet ensemble. F est défne à partr de la pertnence MPRI d'une entté fonctonnelle (cf ). Cette pertnence est fonctons de l'ensemble Se des séquences d'îlots nstancées par un des scénaros de cas d'utlsaton de la zone fonctonnelle et de l'ensemble Sc des scénaros de cas d'utlsaton du système. F : 2 F Λ U R + E = ( E, Sc Se) MPRI, 7

73 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI La foncton d'utlté relatve f ρ mesurant la qualté d'une entté fonctonnelle E par rapport à l'ensemble Λ est défne par rapport à F : f ρ : Λ 2 f ρ E, Λ U La défnton de f ρ à valeur dans E Λ, E Λ F E R + E = F E U U E F U E + R est due à la crossance de F. En effet, U U E F U E = MPRI ( E, Sc, Se) 0 La foncton de mémorsaton f ν permet d'assocer à une entté fonctonnelle E résultante de l'nserton d'un îlot fonctonnel I dans une entté fonctonnelle E 0 le fat qu'elle sot à mémorser ou non en tant que quarter fonctonnel. La foncton f ν est défne par rapport au seul MSIE (cf ) du regroupement dont est ssue l'entté fonctonnelle: f f f ν ν ν : Λ ( 0,) ( E) = MPRI E0U{ I}, ( E) = 0 MPRI E { I}, ( Sc, Se) MSIE( E0, I, Sc, Se) ( 0U Sc, Se) < MSIE( E0, I, Sc, S) La foncton de fltrage f φ supprme les enttés fonctonnelles dont l'utlté relatve est nulle. Cec est équvalent à supprmer les enttés fonctonnelles dont la pertnence est nulle, c'est-à-dre celles dont les îlots fonctonnels n'ont pas de relatons de dépendance nstancées durant les scénaros de Sc. La foncton de mutaton f µ permet de modfer une entté fonctonnelle en lu nsérant un seul îlot fonctonnel. La foncton de mutaton ans défne respecte le fat de ne modfer que légèrement une entté fonctonnelle Algorthme bactérologque A l'ade des fonctons bactérologques défnes dans le , l'algorthme bactérologque est structuré dans un cycle ncrémental consttué des quatre actvtés suvantes : - la mutaton où un îlot est, sot nséré dans une entté fonctonnelle, sot supprmé d'une entté fonctonnelle, - le classement des enttés fonctonnelles, - la mémorsaton des melleures enttés fonctonnelles, - le fltrage permettant de supprmer les mauvases enttés fonctonnelles. 72

74 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI La procédure est décrte dans le dagramme de tâches de la Fgure 37. Fgure 37 : Procédure de concepton automatsée des quarters fonctonnels Chacune des actvtés de la procédure de concepton automatsée des quarters fonctonnels est détallée dans l'algorthme suvant où - NE k représente le nombre d'enttés fonctonnelles résultantes de la k tératon, - I est un îlot fonctonnel, - E k,j est une entté fonctonnelle non vde résultante de la k tératon. /* Intalsaton des enttés fonctonnelles à partr des NE 0 îlots fonctonnels I */ Pour de à NE 0 { } E = { } 0, I ; 73

75 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI /* k tératon */ /* Mutaton */ Pour j de à NE k- { S [, NE ] Alors tré au sort et s le taux de mutaton n'est pas dépassé S 0 U U E k, j f Ek, j, E0, = Ek, j E0, E 0, E k, Alors Fns Fns } = µ, U E k, = fµ Ek,, E0, = Ek, E0, /* Remarques: ( E ) Card( E ) /* Classement */ Pour j de à NE k { Pour l de (j +) à NE k { S f E 0 k, j k, j + U Card et l, E k E { Ø} E U ρ k, j, E, m f ρ k, l, E, m k, m k, m E k, j Ek, l E k, j > Ek, l Alors Snon Fns } } /* Mémorsaton */ Pour j de à NE k { S U U E k, j f Ek, j, E0, = Ek, j E0, Alors = µ,, ju 0, = S ( E k E ) f ν Alors Snon E, est mémorsée k j E, n'est pas mémorsée k j Fns Fns } /* Fltrage */ Pour j de à NE k { U S E k, E 0 f ρ Alors Snon Fns } E k, j E k, j, j, m k, m n'est pas supprmée est supprmée j */, ji k, l, = 74

76 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI L'algorthme bactérologque permettant de concevor les quarters fonctonnels est codé avec le langage SmartQVT [SmartQVT, web] qu mplémente le langage QVT- Operatonal, parte de la norme QVT (Query / Vew / Transformaton) [QVT, web] défne par l'omg (Open Management Group) comme langage de l'approche MDE. 3.6 Expérmentaton avec le SI supportant le processus méter d'usage d'un servce télécom 3.6. Démarche applquée à la zone Messagere Dans le PLU fonctonnel conçu par un groupe d'experts du SI supportant le processus de l'usage d'un servce télécom à France Télécom, l exste actuellement une dzane de zones fonctonnelles, une cnquantane d'îlots fonctonnels et une centane de voes entre îlots. L'llustraton chose est la zone fonctonnelle Messagere dont l'urbanste est actuellement Francs Alzon de France Télécom R&D Concepton experte des zones, des îlots des parcelles et des voes fonctonnels Les îlots fonctonnels de la zone fonctonnelle Messagere sont représentés dans l'extrat de ce PLU fonctonnel Fgure 38. De l'extrat de la zone Messagere, seules les parcelles prses en compte dans l'approche dynamque sont étudées. Fgure 38 : Extrat des îlots, des parcelles et des voes fonctonnels de la zone Messagere conçus par l'expert Les dagrammes de séquence UML sgnfcatfs de l'approche dynamque pour la zone Messagere sont référencés pour chaque scénaro dans le Tableau 6. Scénaro de la zone Messagere Fgure Envoyer un emal Fgure 39 Envoyer un message vocal convert en MMS Fgure 40 Envoyer un message vocal Fgure 4 Recevor un emal nfecté Fgure 42 Notfer par emal une alerte de boîte de messagere Fgure 43 Notfer par emal la lecture d'un emal reçu Fgure 44 Tableau 6 : Références des scénaros llustrant la zone Messagere. 75

77 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Fgure 39 : Scénaro d'envo de message 76

78 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Fgure 40 : Scénaro d'envo d'un message vocal convert en MMS 77

79 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Fgure 4 : Scénaro d'envo d'un message vocal Fgure 42 : Scénaro de récepton d'un emal nfecté 78

80 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Fgure 43 : Scénaro de notfcaton par emal d'une alerte de boîte de messagere Fgure 44 : Scénaro de notfcaton par emal de la lecture d'un emal reçu 79

81 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Typage des îlots fonctonnels Le typage des îlots fonctonnels est fourn par l'urbanste responsable de la zone Messagere. D'après l'équaton 3-, la formulaton de ce typage est la suvante : t t t t t t t ( Sécurté de la messagere) = { Flux} ( Canaux d' échanges de message) = { Flux} ( Structure de message) = { Stock} ( Répondeur - Enregstreur) = { Flux, Stock} ( Archvage de message) = { Stock} ( Tr de message) = { Stock} ( Stratége de communcaton ) = { Stock} Seul, l'îlot fonctonnel Répondeur Enregstreur est mult-typé. En effet la parcelle fonctonnelle Enregstrer un message vocal recouvre : - une parcelle fonctonnelle Envoyer un message vocal qu défnt un îlot de type flux et, - une parcelle fonctonnelle Créer un message vocal qu défnt un îlot de type stock. Cec est équvalent, d'après l'équaton 3-2 à : s ( Répondeur - Enregstreur) = ( Répondeur - Enregstreur - Envo de message vocal, Flux), ( Répondeur - Enregstreur - Créaton de message vocal, Stock) De plus, une relaton de dépendance est créée de l'îlot fonctonnel Répondeur Enregstreur Envo de message vocal vers l'îlot fonctonnel Répondeur Enregstreur Créaton de message vocal conformément à la Règle d'urbansme Flux et stock Concepton automatsée des îlots et voes fonctonnels La dépendance de l'îlot fonctonnel Répondeur Enregstreur vs-à-vs de l'îlot fonctonnel Canaux d'échanges de message est transformée conformément à la Règle d'urbansme Scsson îlot mult-typé en : - une dépendance de l'îlot fonctonnel Répondeur Enregstreur Envo de message vocal de type flux vers l'îlot fonctonnel Canaux d'échanges de message de type flux, - une dépendance de l'îlot fonctonnel Répondeur Enregstreur Envo de message vocal de type flux vers l'îlot fonctonnel Structure de message de type stock, - une dépendance de l'îlot fonctonnel Répondeur Enregstreur Créaton de message vocal de type stock vers l'îlot fonctonnel Structure de message de type stock. Toujours conformément à cette règle, une dépendance de l'îlot fonctonnel Répondeur Enregstreur Créaton de message vocal de type stock vers l'îlot fonctonnel Canaux d'échanges de message de type flux devrat être ajoutée au modèle d'îlots fonctonnels. Cet ajout est mpossble du fat de l'absence du respect de la Règle d'urbansme Flux et stock. Le résultat de la transformaton du modèle des îlots fonctonnels de la zone Messagere conformément à la Règle d'urbansme Scsson îlot mult-typé et à la Règle d'urbansme Flux et stock est représentée Fgure

82 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Fgure 45 : Extrat des îlots et des voes fonctonnels de la zone messagere contrants par le typage des îlots 8

83 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Seul le scénaro d'envo d'un message vocal est modfé sute à l'évoluton du modèle d'îlots fonctonnels. La parcelle Enregstrer un message vocal est scndée en deux nteractons conformes au modèle d'îlots fonctonnels de la Fgure 45 : - Envoyer un message vocal du scénaro d'envo de message vocal vers l'îlot fonctonnel Répondeur Enregstreur Envo de message vocal - Créer un message vocal de l'îlot fonctonnel Répondeur Enregstreur Envo de message vocal vers l'îlot fonctonnel Répondeur Enregstreur Créaton de message vocal Fgure 46 : Scénaro d'envo d'un message vocal contrant par le typage des îlots 82

84 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Mesure de l'algnement avec la vue méter Le processus méter d'envo de message électronque est décrt dans le dagramme d'actvtés UML de la Fgure 9. L'algnement des parcelles fonctonnelles avec la vue méter proposé par l'urbanste fonctonnel responsable de la zone Messagere est reporté dans le Tableau 7. Parcelle fonctonnelle Actvté méter Exécuter une règle de sécurté de la messagere Envoyer un message Envoyer un message Envoyer un message Délvrer un message Recevor un message Délvrer un message Transmettre un message Envoyer un message Edter un message Créer un message Composer un message Enregstrer un message Convertr le format d'un message Envoyer un message Créer un message vocal Composer un message Envoyer un message vocal Envoyer un message Délvrer un message Modfer un message vocal Composer un message Stocker un message Consulter une règle de tr de message Délvrer un message Consulter la stratége de récepton de message Envoyer un message Tableau 7 : Algnement des parcelles fonctonnelles de la zone Messagere avec les actvtés méter du processus d'envo de message électronque. L'algnement des relatons de dépendance entre parcelles fonctonnelles avec la vue méter est évalué dans le Tableau 8 de façon automatque. L'évaluaton est fate pour chaque scénaro. Scénaro Envoyer un emal Envoyer un message vocal convert en MMS Relaton de dépendance entre parcelles fonctonnelles Envoyer un message vers Transmettre un message Transmettre un message vers Stocker un message Stocker un message vers Consulter une règle de tr de message Envoyer un message vers Consulter la stratége de récepton de message Envoyer un message vers Convertr le format d'un message Envoyer un message vers Transmettre un message Transmettre un message vers Stocker un message Relaton de successon entre actvtés méter Envoyer un message vers elle-même Non algnée (relaton de dépendance nverse) Délvrer un message vers elle-même Envoyer un message vers elle-même Envoyer un message vers elle-même Envoyer un message vers elle-même Non algnée (relaton de dépendance nverse) 83

85 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Envoyer un message vocal Recevor un emal nfecté Notfer par emal une alerte de boîte de messagere Notfer par emal la lecture d'un emal reçu Envoyer un message vocal vers Créer un message vocal Envoyer un message vocal vers Créer un message Envoyer un message vocal vers Enregstrer un message Envoyer un message vocal vers Envoyer un message Envoyer un message vers Stocker un message Recevor un message vers Exécuter une règle de sécurté de la messagere Recevor un message vers Stocker un message Envoyer un message vers Stocker un message Envoyer un message vers Stocker un message Composer un message vers Envoyer un message Composer un message vers Envoyer un message Composer un message vers Envoyer un message Envoyer un message vers elle-même Délvrer un message vers elle-même Envoyer un message vers Délvrer un message Délvrer un message vers elle-même Délvrer un message vers elle-même Délvrer un message vers elle-même Tableau 8 : Algnement des relatons de dépendance entre parcelles fonctonnelles de la zone Messagere avec les relatons de successon entre actvtés méter du processus d'envo de message électronque. La mesure MAFM de l'algnement de la vue fonctonnelle de la zone Messagere par rapport à la vue méter est d'après l'équaton 3-3 : pusque MAFM ( zone Messagere) = = N ( zone Messagere) = 3 et ( zone Messagere) = 0 p N pusque les 3 parcelles nap sont algnées d'après le Tableau 7, N zone Messagere = pusque 2 relatons de - N ( zone Messagere) = 6 et ( ) 2 r nar dépendance entre parcelles ne sont pas algnées d'après le Tableau 8. 84

86 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Un blan de cet algnement est envoyé à l'urbanste fonctonnel responsable de la zone Messagere. L'objectf est de lu permettre de valder la vue fonctonnelle de la zone ou de la fare évoluer. Le blan est le suvant: - L'algnement de la vue fonctonnelle de la zone Messagere avec le processus méter d'envo de message électronque serat parfat (c'est-à-dre mesuré à ) s la relaton de dépendance entre o la parcelle fonctonnelle Transmettre un message de l'îlot Canaux d'échanges de message et o la parcelle fonctonnelle Stocker un message de l'îlot fonctonnel Archvage de message état nversée. Cette nverson nécessterat de scnder l'îlot fonctonnel Canaux d'échange de message en deux îlots : - Canaux d'échange de message Envo de message défn par la parcelle fonctonnelle Envoyer un message - Canaux d'échange de message Transmsson de message défn par la parcelle fonctonnelle Transmettre un message. Dans ce cas, les tros relatons de dépendance suvantes permettraent un algnement parfat : - une relaton de dépendance de l'îlot fonctonnel Canaux d'échange de message Envo de message vers l'lot fonctonnel Canaux d'échange de message Transmsson de message, - une relaton de dépendance de l'îlot fonctonnel Archvage de message vers l'lot fonctonnel Canaux d'échange de message Transmsson de message, - une relaton de dépendance de l'îlot fonctonnel Canaux d'échange de message Envo de message vers l'lot fonctonnel Archvage de message. La deuxème relaton de dépendance n'est possble d'après Règle d'urbansme Flux et stock que s l'îlot fonctonnel Archvage de message état de type flux. Ce changement de type revent à consdérer que la parcelle fonctonnelle Stocker un message ne produt qu'une date de stockage et non le message stocké. L'hypothèse pour la sute de l'expérmentaton est que l'urbanste fonctonnel a valdé la vue fonctonnelle de la zone Messagere avec un algnement avec la vue méter mesuré à 7/8. L'apprécaton réelle de l'urbanste fonctonnel sur le blan de l'algnement est reportée dans l'évaluaton de la démarche DA4EA du

87 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Concepton automatsée des quarters fonctonnels Le temps d'exécuton du programme mplémentant l'algorthme bactérologque, pour un taux de mutaton varant de 0% à 00%, est représenté dans la Fgure 47. Ce temps correspond à la vtesse de convergence de l'algorthme bactérologque. Dès que la convergence est attente, le temps d'exécuton devent en effet néglgeable. temps d'exécuton / taux de mutaton temps d'exécuton (ms) taux de mutaton (%) Fgure 47 : Temps d'exécuton de l'algorthme bactérologque par taux de mutaton La convergence la plus rapde de l'algorthme bactérologque se stue pour un taux de mutaton bas (entre 0% et 0%) ou pour un taux de mutaton élevé (entre 70% et 00%). Dans ces deux cas, l'algorthme bactérologque converge pour un mnmum local. La mutaton est sot trop lente pour un taux de mutaton bas, sot trop rapde pour un taux de mutaton élevé, pour attendre de bons mnma. La conséquence est que l'algorthme ne génère pas un nombre sgnfcatf d'enttés fonctonnelles de qualté pour un taux de mutaton fable ou un taux de mutaton élevé. Les autres résultats de l'algorthme bactérologque sont donc détallés c-après avec un taux de mutaton varant de 5% à 50%. Pour chaque taux de mutaton, le nombre cumulé d'enttés fonctonnelles résultat de séres de dx exécutons de l'algorthme, est représenté dans la Fgure

88 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI nombre d'enttés fonctonnelles / taux de mutaton nombre d'enttéss taux de mutaton (%) Fgure 48 : Nombre d'enttés fonctonnelles générées par l'algorthme bactérologque par taux de mutaton Plus le taux de mutaton augmente, plus le nombre d'enttés fonctonnelles générées par l'algorthme dmnue. En effet, la convergence vers des enttés fonctonnelles à couplage fort est favorsée par un taux de mutaton élevé. La défnton de la foncton bactérologque de fltrage dans le mplque que les solutons à couplage plus fable ne sont pas prses en compte. Plus le taux de mutaton est fable, plus le nombre moyen d'îlots fonctonnels par entté fonctonnelle augmente. La rason est un couplage plus fable des îlots de l'entté fonctonnelle lorsque le taux de mutaton est fable. La convergence vers un nombre d'enttés fonctonnelles stable est de ce fat plus lente. Lorsque le taux de mutaton est élevé, les enttés fonctonnelles ayant un couplage fort entre leurs îlots sont rapdement générées. Du fat de la foncton de classement, chaque entté fonctonnelle ans conçue n'nsère pas d'îlots fonctonnels dmnuant fortement son couplage. La convergence vers un nombre d'enttés fonctonnelles stable est de ce fat plus rapde. L'allure de la courbe du temps d'exécuton par rapport au taux de mutaton est donc très corrélée à la courbe du nombre d'enttés fonctonnelles générées. Le nombre d'enttés fonctonnelles pour un taux de mutaton supéreur à 50% non représenté dans la Fgure 48 contnue de décrotre jusqu'à une valeur nulle pour un taux de 00%. 87

89 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI La qualté moyenne d'une entté fonctonnelle est représentée dans la Fgure 49 par rapport à une estmaton a posteror de son potentel à devenr un quarter fonctonnel. Cette estmaton respecte une notaton de 0 à 3 à partr de l'ntensté du couplage entre îlots fonctonnels d'une même entté fonctonnelle : - 3 entté fonctonnelle à couplage très fort, - 2 entté fonctonnelle à couplage fort, - entté fonctonnelle à couplage moyen, - 0 entté fonctonnelle à couplage fable. qualté moyenne des enttés fonctonnelles / taux de mutaton qualté moyenne des enttés taux de mutaton (%) Fgure 49 : Qualté moyenne des enttés fonctonnelles mémorsées par taux de mutaton La qualté moyenne des enttés fonctonnelles mémorsées est crossante. Le premer résultat est que, quelque sot le taux de mutaton, la qualté des enttés fonctonnelles mémorsées par l'algorthme bactérologque représente au mnmum un couplage moyen fort. La foncton de mémorsaton des melleures enttés fonctonnelles dépendante du seul de regroupement ans que la foncton de fltrage des plus mauvases enttés fonctonnelles dépendantes de la pertnence de l'entté fonctonnelle sont donc effcaces. La qualté moyenne des enttés fonctonnelles pour un taux de mutaton supéreur à 50% non représenté dans la Fgure 49 se stablse. 88

90 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI La qualté cumulée des enttés fonctonnelles mémorsées est représentée dans la Fgure 50. qualté cumulée des enttés fonctonnelles / taux de mutaton qualté des enttés taux de mutaton (%) Fgure 50 : Qualté cumulée des enttés fonctonnelles mémorsées par taux de mutaton Par comparason avec le nombre d'enttés fonctonnelles générées, et donc non fltrées de la Fgure 49, le maxmum de qualté attent pour les enttés fonctonnelles ne correspond pas au maxmum du nombre d'enttés fonctonnelles. Ce maxmum est attent pour un taux de mutaton de 25% pour la qualté cumulée alors que le maxmum du nombre d'enttés fonctonnelles générées est attent pour un taux de mutaton de 0%. Cec sgnfe, que l'optmum de génératon des quarters fonctonnels est un comproms à attendre entre ces deux courbes. Le nombre d'enttés fonctonnelles mémorsées pour un taux de mutaton supéreur à 50%, non représenté dans la Fgure 50, contnue de décrotre jusqu'à une valeur nulle attente pour un taux mutaton de 00%. Les enttés fonctonnelles E les plus fréquemment générées lors de cette concepton automatsée des quarters fonctonnels sont par ordre de gan (quotent de la pertnence de l'entté par le seul du regroupement dont l'entté est le résultat) :. E = { Répondeur - Enregstreur - Envo de message vocal,structure de message} 2. Répondeur - Enregstreur - Envo de message vocal, E = Répondeur - Enregstreur - Créaton de message vocal, Structure de message E = Canaux d'échange de message, Archvage de message E = Canaux d'échange de message,archvage de message, Tr de message Canaux d'échange de message, Archvage de message, E = Répondeur - Enregstreur - Envo de message vocal E = Canaux d'échange de message, Archvage de message, Structure de message Répondeur - Enregstreur - Envo de message vocal, E = Répondeur - Enregstreur - Créaton de message vocal Répondeur - Enregstreur - Envo de message vocal, E = Canaux d'échange de message 3. { } 4. { } { }

91 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI 3.7 Évaluaton de la démarche DA4EA Lors du prototypage de la démarche DA4EA, l'actvté de valdaton du PLU fonctonnel entourée dans la Fgure 5 recouvre l'évaluaton de la démarche. La démarche est évaluée par les urbanstes fonctonnels qu l'ont prototypée. Fgure 5 : Actvté de valdaton du PLU fonctonnel dans la démarche DA4EA Le prototypage de la démarche DA4EA a eu leu en avrl 2008 à partr de deux zones fonctonnelles : - la zone Messagere, nommée Z dans l'évaluaton, sur laquelle la démarche dans sa totalté est expérmentée (cf. 3.6.), - la zone Devce, nommée Z2 dans l'évaluaton, dont l'urbanste est Benot Hellequn de France Télécom R&D, est dédée aux termnaux. Seule l'actvté d'algnement avec la vue méter n'est pas évaluée pour cette zone. Dans les deux cas, l'urbanste, expert de la zone fonctonnelle, a réalsé pluseurs ncréments de la démarche DA4EA. Le document en entrée du prototypage de la démarche est la descrpton d'une zone fonctonnelle par cet expert. La seule dfférence entre les deux zones est que les quarters de la zone Messagere étaent conçus au préalable, alors qu'ls ne l'étaent pas pour la zone Devce. Chaque tératon due à l'urbanste fonctonnel peut être lée à : - une modfcaton du typage des îlots fonctonnels, - un ajout d'une ou pluseurs parcelles fonctonnelles, - à l'ajout de voes entre îlots fonctonnels sute à la scsson d'un îlot en un îlot de type flux et un îlot de type stock. 90

92 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI 3.7. Contexte du prototypage de la démarche DA4EA Le prototypage de la démarche DA4EA a été accompagné d'un support par le concepteur de la démarche. Un outllage d'actvtés automatsées a complété ce support. Après la mse en œuvre de la démarche DA4EA par l'urbanste responsable de la zone fonctonnelle étudée, un questonnare lu a été proposé. Un blan de la démarche a été réalsé à partr des réponses à ce questonnare. Le questonnare content dx questons rattachées à quatre thèmes : - l'approche DA4EA, avec une évaluaton de la complexté de l'approche par rapport à son ntérêt pour l'urbanste, - le contenu archtectural ssu de l'applcaton de la démarche DA4EA avec une évaluaton de l'archtecture obtenue et de la qualté de la concepton, en partculer en termes de traçablté, - le coût de l'approche DA4EA comparé au coût de l'approche de concepton d'une zone fonctonnelle par un expert sans automatsaton d'actvtés, - le blan détallé par actvté automatsée de la démarche DA4EA Approche DA4EA Q. Trouvez-vous l'approche DA4EA "très complquée complquée smple très smple" à mettre en œuvre? Q2. Trouvez-vous l'approche DA4EA "sans ntérêt pas très utle utle essentelle" pour votre traval d'urbanste fonctonnel? Q3. Trouvez-vous le support de cette approche DA4EA "sans ntérêt pas très utle utle essentel"? Urbansme et approche DA4EA Q4. L'archtecture de votre zone fonctonnelle conçue avec DA4EA est-elle "vrament pre pre melleure vrament melleure" que l'archtecture de la zone fonctonnelle précédente? Q5. La qualté de la concepton de votre zone fonctonnelle conçue avec DA4EA est-elle "vrament pre pre melleure vrament melleure" que la qualté de la zone fonctonnelle précédente? Coût de l'approche DA4EA Q6. Le coût de la concepton d'une zone fonctonnelle avec DA4EA est-l "vrament plus mportant plus mportant mons mportant vrament mons mportant" que le coût de concepton précédent? Automatsaton et approche DA4EA Q7. La défnton des îlots, et des voes entre îlots, de votre zone fonctonnelle avec la démarche DA4EA est-elle " vrament pre pre melleure vrament melleure" que la défnton actuelle? Q8. Trouvez-vous la mesure de l'algnement de la vue fonctonnelle avec la vue méter proposée par la démarche DA4EA "sans ntérêt pas très utle utle essentelle"? Q9. Trouvez-vous le blan fasant sute à la mesure d'algnement de la vue fonctonnelle avec la vue méter proposée par la démarche DA4EA "sans ntérêt pas très utle utle essentel" pour votre traval d'urbanste fonctonnel? Q0. Trouvez-vous les résultats de la concepton bactérologque des quarters fonctonnels proposée par la démarche DA4EA "vrament pre pre melleure vrament melleure" que les quarters précédents? 9

93 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Blan du prototypage de la démarche DA4EA Les réponses de chaque urbanste responsable de zone fonctonnelle (Z à Z2) sont reportées dans le Tableau 9 de la façon suvante : - Q : approche très complquée " ", complquée "-", smple "+", très smple "++", - Q2 : approche sans ntérêt " ", peu utle "-", utle "+", essentelle "++", - Q3 : support sans ntérêt " ", peu utle "-", utle "+", essentel "++", - Q4 : archtecture de la zone vrament pre " ", pre "-", melleure "+", vrament melleure "++", - Q5: qualté de la concepton vrament pre " ", pre "-", melleure "+", vrament melleure "++", - Q6 : coût vrament plus mportant " ", plus mportant "-", mons mportant "+", vrament mons mportant "++", - Q7 : défnton des îlots et des voes vrament pre " ", pre "-", melleure "+", vrament melleure "++", - Q8 : mesure d'algnement avec la vue méter sans ntérêt " ", peu utle "-", utle "+", essentelle "++", - Q9 : blan de l'algnement avec la vue méter sans ntérêt " ", peu utle "-", utle "+", essentel "++", - Q0 : concepton des quarters vrament pre " ", pre "-", melleure "+", vrament melleure "++". Zone Approche Urbansme Coût Automatsaton fonctonnelle Q Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q0 Z Z Tableau 9 : Réponses au questonnare du blan de la démarche DA4EA Analyse du blan du prototypage de la démarche DA4EA Même s le nombre de zones conçues lors du prototypage de la démarche DA4EA est fable, de premers ensegnements peuvent être trés (cf. Fgure 52) : - le retour des deux responsables de zone fonctonnelle est globalement postf, - l'approche DA4EA est très ntéressante et smple, - les actvtés automatsées ont de bons retours quant à la qualté des résultats, - parm ces actvtés automatsées, l'algnement de la zone fonctonnelle avec la vue méter et son évaluaton ont eu un très bon retour de l'urbanste qu a pu les mettre en œuvre, - le coût est mons mportant que celu des ancennes approches du fat de l'outllage d'actvtés automatsées. 92

94 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Blan de la démarche DA4EA Concepton des quarters Blan algnement Algnement méter Smplcté Intérêt Utlté de l'assstance Archtecture de zone Défnton des îlots Qualté Décrossance du coût Fgure 52 : Blan de la démarche DA4EA En complément de l'automatsaton outllée de certanes actvtés, la nécessté d'une formaton adressée aux urbanstes fonctonnels est apparue lors du blan. 93

95 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI Blan comparatf avec la zone Messagere exstante En préalable de l'évaluaton de la démarche par l'urbanste fonctonnel (cf. 3.7), un blan comparatf est dressé entre la zone fonctonnelle Messagere conçue avec la démarche DA4EA et la zone Messagere exstante. Ce blan content des éléments chffrés de comparason entre l'archtecture fonctonnelle de la zone Messagere conçue totalement par des experts et l'archtecture fonctonnelle de la zone avec la démarche DA4EA. Le blan est fat pour les concepts du PLU fonctonnel mpactés par la démarche DA4EA, soent, dans l'ordre de la démarche, l'îlot, la voe et le quarter. Le Tableau 0 représente l'algnement de chacun de ces concepts entre la vue fonctonnelle entèrement conçue par l'urbanste fonctonnel expert de la zone Messagere, et la vue fonctonnelle générée par la démarche DA4EA. Zone Messagere DA4EA / Zone Messagere "expert" Îlot Algné 6 Non algné 2 Voe Algnée 5 Non algnée 4 Quarter Algné 0 Non algné 2 Tableau 0 : Algnement de la zone Messagere "expert" et de la zone Messagere DA4EA. Le non algnement des îlots fonctonnels et des voes fonctonnelles est dû à la scsson de l'îlot fonctonnel mult-typé Répondeur Enregstreur. Néanmons, les voes de la zone Messagere conçue unquement par l'expert sont reportées sur au mons un des îlots fonctonnels ssus de la scsson : - la voe de l'îlot Répondeur Enregstreur vers l'îlot Canaux d'échanges de message est reportée sur l'îlot Répondeur Enregstreur Envo de message vocal, - la voe de l'îlot Répondeur Enregstreur vers l'îlot Structure de message est reportée sur l'îlot Répondeur Enregstreur Envo de message vocal et sur l'îlot Répondeur Enregstreur Créaton de message vocal. Aucune des enttés fonctonnelles générées par l'algorthme bactérologque ne correspond à un des quarters conçus par l'urbanste fonctonnel de la zone Messagere. Comme pour l'algnement entre la vue fonctonnelle de la zone et le processus méter supporté, l'évaluaton par l'urbanste de ces quarters non algnés est reportée dans le

96 La démarche DA4EA d'urbansaton de la vue fonctonnelle d'un SI 3.8 Concluson La synthèse par thèmes du blan de la démarche DA4EA (cf. 3.7) est reportée dans la Fgure 53 avec : - l'ntérêt et la pertnence de l'approche, - l'ntérêt de l'automatsaton pour assster l'urbanste fonctonnel lors de la concepton de sa zone fonctonnelle, - l'apport de la démarche DA4EA lors de la concepton d'une zone fonctonnelle, - un coût mons mportant que celu des approches précédentes. Synthèse du blan de la démarche DA4EA APPROCHE AUTOMATISATION ARCHITECTURE COÛT Fgure 53 : Synthèse du blan de la démarche DA4EA Le bon résultat du blan, malgré le peu d'expérmentatons fates avec la démarche DA4EA, est nstructf sur l'apport d'une automatsaton de certanes actvtés avec l'ngénere des modèles. Cette automatsaton permet d'offrr un coût de concepton mons mportant et de rendre plus smple l'approche pour l'urbanste utlsateur de la démarche. 95

97

98 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI 4. La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI 4. Prncpes En reprenant l'llustraton du logement (cf ), le problème à résoudre est la détermnaton, pour tous logements à bâtr, d'une méthode de constructon tenant compte du logement modèle conçu fonctonnellement avec la démarche DA4EA. Cette démarche qu s'nscrt dans le processus de développement EUP [Ambler, 2005] dot faclter la prse en compte de l'ea par les développeurs de systèmes. C'est l'objectf de la démarche EA4UP qu a la proprété d'ntégrer un PLU fonctonnel [Smonn, 2008]. 4.. Pourquo l'urbansme fonctonnel? Un SI devent durable grâce, en partculer, à la réutlsaton de ses systèmes. Cette réutlsaton est favorsée par la descrpton partagée de la vue fonctonnelle de chacun de ces systèmes. La descrpton partagée s'appue sur la vue fonctonnelle du SI telle que conçue avec la démarche DA4EA. Les lens entre vues sont nsprées du cycle de développement en Y tel que celu reprs dans le processus de développement 2TUP (2 Track Unfed Process) [Roques, 2004]. Le cycle en Y est tel que la vue applcatve d'un système réalse l'analyse fonctonnelle de ce système et est déployée sur son archtecture technque. L'nserton de la vue fonctonnelle du SI et de la vue méter de l'entreprse nécesste de compléter ce cycle. Les relatons entre la vue fonctonnelle d'un système et les autres vues du cadre de l'urbansme sont représentées dans le dagramme de classes de la Fgure 54. Cœur de méter de l'entreprse Système d'informaton Systèmes nformatques Fgure 54 : Vues du cadre de l'urbansme, cœur de méter de l'entreprse, SI et systèmes La vue fonctonnelle du SI supporte la vue méter de l'entreprse. Par rapport aux concepts de ces deux vues défns dans le et dans le , cec sgnfe que les îlots fonctonnels et leurs parcelles supportent chaque procédure méter de l'entreprse. L'algnement entre la vue fonctonnelle et la vue méter défn dans le 3.4 llustre cette noton de support d'une vue par l'autre. 97

99 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI La vue technque, qu est propre aux systèmes nformatques, satsfat la vue méter de l'entreprse. Dans le contexte d'une entreprse telle que France Télécom, les nœuds d'exécuton et les protocoles défns dans le satsfont les procédures méter lées aux réseaux nouvelles génératons (NGN : Next-Generaton Networks) [Knghtson, 2005] tels que ceux respectant l'envronnement archtectural IMS (IP Multmeda Subsystem) [Cuevas, 2006]. La vue applcatve, propre aux systèmes nformatques comme la vue technque, représente la réalsaton de la vue fonctonnelle des systèmes déployés sur la vue technque. Toutes les parcelles fonctonnelles du SI ne sont pas oblgatorement réalsées par un élément d'un système nformatque. C'est par exemple le cas de la réalsaton par un acteur human d'une parcelle fonctonnelle de transmsson d'un bon de commande sas en front-offce pour tratement en back-offce. Chacune de ces vues possède un aspect dynamque (cf ). Pour chaque vue, l exste en effet un len avec des nteractons réalsant l'usage d'un système. Pour la vue fonctonnelle, l'aspect dynamque peut être modélsé par des dagrammes de séquence UML représentant les nteractons entre îlots fonctonnels nstancées lors du déroulement d'un scénaro de cas d'utlsaton d'un système (cf. 3.2). Il en est de même pour la vue applcatve où des nterfaces applcatves de type requête ou de type réponse sont défnes afn de permettre des nteractons entre nstances de composants applcatfs. Défnton : Une nterface applcatve représentant une nteracton entre nstances de composants applcatfs est : - de type requête s l'nteracton est une demande ou s l'nteracton correspond à l'émsson de paramètres d'entrée d'une requête, - de type réponse s l'nteracton est une réponse à une demande ou s l'nteracton correspond à l'émsson de paramètres de sorte d'une requête Pourquo une approche dynamque? L'archtecture SOA nécesste de consdérer l'aspect dynamque de chaque vue d'archtecture. Chaque procédure de la vue méter est en effet supportée par une séquence de servces. Dans la démarche EA4UP, la séquence de servces est représentée dans la vue fonctonnelle du système par une séquence d'nteractons entre un scénaro et un îlot fonctonnel. Chaque nteracton est du type requête ou du type réponse. Elle correspond à une parcelle fonctonnelle nstancée lors de l'nteracton. La séquence d'nteractons entre un scénaro et un îlot fonctonnel est réalsée dans la vue applcatve par une séquence d'nteractons entre le scénaro et les composants applcatfs. Ces nteractons correspondent à l'utlsaton des nterfaces applcatves de ces composants. La défnton des nteractons sgnfe la réutlsaton des îlots fonctonnels ou celle des composants applcatfs. L'utlsaton d'un îlot fonctonnel ndut en effet un accès à une donnée par l'ntermédare d'une de ses parcelles fonctonnelles. Cet accès ndut une nteracton avec cet îlot fonctonnel. Il en est de même pour un composant applcatf et son nterface. L'nterface applcatve offre en effet un accès à ce composant durant une nteracton réalsant un cas d'utlsaton d'un système. 98

100 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI La relaton de dépendance pour les concepts de la vue applcatve est défne de façon analogue à la relaton de dépendance pour les concepts de la vue fonctonnelle (cf et 3.5.2). Défnton : - deux nterfaces applcatves sont en relaton de dépendance s toutes deux sont exclusvement du type requête, ou du type réponse, et s l'une d'entre elles succède à l'autre dans un dagramme de séquence UML représentant un scénaro. Une nterface applcatve IA succède à une nterface applcatve IA 2 s la lgne de ve cble de IA 2 est la lgne de ve à l'orgne de IA ; - deux composants applcatfs sont en relaton de dépendance s'l exste une nteracton de type requête de l'un vers l'autre dans un dagramme de séquence UML. Le composant à l'orgne de l'nteracton dépend du composant à la cble de cette nteracton. Le prncpe est d'axer la concepton de la vue fonctonnelle et la concepton de la vue applcatve sur l'aspect dynamque de l'usage du système. L'archtecte du système dot en effet dédure la concepton d'une relaton de dépendance entre deux îlots fonctonnels, ou une relaton de dépendance entre deux composants applcatfs, à partr du déroulement d'un scénaro. D'après la Règle d'urbansme Interactons et voes du 3.2, la relaton de dépendance se tradut par une nteracton entre les nstances de ces îlots fonctonnels ou entre les nstances de ces composants applcatfs. La Sémantque UML Approche dynamque et dagramme de séquence (cf. 2..5) est llustrée dans le cas des îlots fonctonnels par la Fgure 55. L'nteracton Interacton2 représente une relaton de dépendance de l'îlot fonctonnel I vs-à-vs de l'îlot fonctonnel I2 L'nteracton Interacton du scénaro vers l'îlot fonctonnel I précède l'nteracton Interacton3 du scénaro vers l'îlot fonctonnel I3 Fgure 55 : Ordonnancement temporel et relaton de dépendance dans un dagramme de séquence De même, l exste une cohérence des relatons de dépendance entre parcelles fonctonnelles, ou entre composants applcatfs, avec les relatons de dépendance entre les données produtes, respectvement, par ces parcelles ou par ces composants. La Règle d'urbansme Relaton de dépendance entre données précse les condtons de dépendance au sens UML entre deux données logques de la vue fonctonnelle ou deux données physques de la vue applcatve. 99

101 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Règle d'urbansme Relaton de dépendance entre données n 6 - une relaton de dépendance entre parcelles fonctonnelles de type requête mplque une relaton de dépendance au sens UML entre les données logques produtes par ces parcelles fonctonnelles ; - une donnée logque DL produte par une parcelle fonctonnelle de type requête dépend a pror d'une donnée logque DL 2 utlsée par la parcelle. La condton est la relaton de dépendance de la parcelle fonctonnelle produsant la donnée logque DL vs-à-vs de la parcelle fonctonnelle produsant la donnée logque DL 2, - une relaton de dépendance entre nterfaces applcatves de type requête mplque une relaton de dépendance au sens UML entre les données physques produtes par ces nterfaces applcatves ; - une donnée physque DP fourne par une nterface applcatve de type requête dépend a pror d'une donnée physque DP 2 utlsée par l'nterface. La condton est la relaton de dépendance de l'nterface applcatve de type requête produsant la donnée physque DP vs-à-vs de l'nterface applcatve de type requête produsant la donnée physque DP Démarche EA4UP et ngénere des modèles La durablté d'un SI est lée à la réutlsaton des éléments de ce SI. Le chox est fat dans la démarche EA4UP de soulgner cette réutlsaton dès la concepton de la vue fonctonnelle et durant la concepton de la vue technque du système. Un élément réutlsable possède en effet une vue applcatve déjà conçue. Cette vue applcatve réalse une vue fonctonnelle de l'élément et est déployée sur sa vue technque. Afn de cadrer au meux la réutlsaton d'un élément du SI lors de la concepton de l'archtecture d'un système, une dépendance supplémentare de la vue technque vs-à-vs de la vue fonctonnelle est ajoutée (cf. Fgure 56). Les vues d'archtecture d'un système sont donc toutes nterdépendantes. Fgure 56 : Vues d'archtecture d'un système et démarche DA4EA Du fat de ces nterdépendances, la plupart des actvtés sont assmlables à des transformatons de modèles telles que décrtes dans l'approche MDE ou dans l'approche MDA (cf ). Par exemple, un modèle de la vue technque est drectement ou ndrectement ssu d'une transformaton de modèles contrante par un modèle de la vue fonctonnelle. C'est le cas de l'analyse technque où les exgences non fonctonnelles sont contrantes par l'analyse fonctonnelle du système. Chaque exgence non fonctonnelle est en effet assocée à un ou pluseurs éléments ssus de l'analyse du système. Ces transformatons de modèle sont réalsées dans la démarche EA4UP par des experts ou sont automatsées. Dans le premer cas, la transformaton est une concepton assstée d'un contrôle du respect de règles d'urbansme (cf ). Dans le second cas, l'automatsaton nécesste en amont un codage des éléments du PIM par des éléments du PDM. Le PIM est un modèle produt lors du développement du système et le PDM est un modèle de référence conçu par les urbanstes. Le codage est une assocaton, réalsée par un développeur du système, de chaque élément du PIM avec un ou pluseurs éléments du PDM. Cette assocaton est en générale représentée dans le méta-modèle des vues d'urbansme par une assocaton entre le ou les concepts nstancés dans le PIM et le ou les concepts nstancés dans le PDM assocé. 00

102 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le modèle de référence pour la vue fonctonnelle est le PLU fonctonnel (cf. 4..). Pour la vue technque, le modèle de référence est un ensemble de préconsatons de solutons technques ou de vue technque d'éléments réutlsables du SI. La vue applcatve de ces éléments consttue le modèle de référence de la vue applcatve. Le rôle de l'expert dans le cas d'une automatsaton de l'actvté est de concevor une vue en s'adant des solutons produtes de façon automatque. Défnton : Lors d'une transformaton de modèle contrante par un PDM, une actvté de codage consste à assocer un ou pluseurs éléments du PDM à chaque élément du PIM. Le résultat du codage permet la transformaton de modèle grâce à l'applcaton de règles d'urbansme. Une llustraton du codage est la transformaton d'un modèle d'enttés en un modèle de données logques de la vue fonctonnelle. L'actvté de codage est c l'assocaton de chaque entté à un ou pluseurs îlots fonctonnels produsant les données extrates de l'entté [Smonn, 2007]. La règle d'urbansme contragnant la transformaton est la Règle d'urbansme Donnée produte et îlot fonctonnel du Dans cette approche d'ngénere des modèles, pluseurs sortes de transformaton de modèle sont mses en œuvre dans la démarche EA4UP. La démarche EA4UP peut être résumée à un enchaînement de transformatons de modèles réalsées par des experts ou automatsées. La démarche EA4UP est fondée sur des transformatons de modèle à partr de la défnton d'un PIM, d'un PSM et parfos d'un PDM. Le PDM est dans notre approche une extenson de la noton de PDM défne par l'omg. Dans EA4UP, l'orgnalté de l'utlsaton de l'approche MDA est d'assmler les modèles conçus par les urbanstes fonctonnels, les modèles conçus par les urbanstes technques ou les modèles conçus par les urbanstes applcatfs à des PDM. La rason est que ce rôle de modèle défnssant des contrantes lors d'une transformaton de modèles joué par le PDM prend tout son sens avec les modèles d'ea d'un SI, en partculer d'un SI durable. Tous les modèles d'archtecture résultant du développement d'un système dovent en effet respecter au meux les modèles d'ea les concernant : - le PLU fonctonnel d'un SI, tel que conçu avec la démarche DA4UP, contrant la vue fonctonnelle d'un système du SI, - l'ensemble de préconsatons, sot purement technques, sot défnes par la vue technque d'éléments à réutlser du SI, contrant la vue technque du système à développer, - les composants applcatfs réutlsables et leurs nterfaces contragnent la concepton de l'archtecture applcatve d'un système. Chaque actvté de la démarche EA4UP, en dehors de celles composant la macroactvté de collecte des exgences, possède au mons une actvté en amont. Ces actvtés nécesstent donc en entrée le résultat d'une actvté amont représentée par un PIM dans l'actvté en cours. De plus, elles peuvent être contrantes par le résultat d'une autre actvté amont représentée par un PSM, résultat de cette actvté. La démarche EA4UP consste alors en un enchaînement de transformatons de modèles tel qu'llustré dans la Fgure 57. 0

103 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PIM 2 PIM PIM 3 = PSM PSM 2 PSM 3 Fgure 57 : Enchaînement de transformatons de modèle Dans cette llustraton : - le modèle PSM résulte d'une transformaton du modèle PIM dans une actvté amont, - le modèle PSM 2 résulte d'une transformaton du modèle PIM 2 dans une actvté amont, - le modèle PSM 3 résulte d'une transformaton du modèle PIM 3 dans une actvté en cours, - dans cette actvté en cours, le modèle en entrée de la transformaton PIM 3 est égal au modèle PSM, - toujours, dans l'actvté en cours, le modèle PSM 2 contrant la transformaton du modèle PIM 3 vers le modèle PSM 3. Les transformatons lées aux actvtés des macro-actvtés d'archtecture sont de plus contrantes par un PDM représentant le cadre de l'urbansme à applquer. Chacune de ces transformatons peut être automatsable ou sous la responsablté complète d'un expert. La responsablté de l'expert est en partculer nécessare lors d'un codage d'éléments du PIM par des éléments du PDM. La Fgure 58 llustre le cas où la transformaton décrte dans la Fgure 57 est telle que : - le modèle PIM est transformé en un modèle PSM par un expert, - le modèle PIM 2 est transformé en un modèle PSM 2 avec la contrante du modèle PSM et d'un PDM, - La transformaton du modèle PIM 2 en un modèle PSM 2 est automatque. 02

104 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PIM Expertse PSM PIM 2 PDM Automatsaton PSM 2 Fgure 58 : Enchaînement de transformatons de modèle, d'expert ou automatsable, dont l'une est conforme à un PDM La successon d'une actvté d'expert pour une approche statque par une actvté automatsée pour une approche dynamque peut être représentée par un enchaînement de transformatons de modèles (cf ). Plus précsément, une actvté dynamque nécesste dans la démarche EA4UP le résultat en entrée de l'aspect statque de cette actvté. L'étude des nteractons entre éléments nécesste en effet au préalable la défnton de ces éléments. Cette actvté statque est en fat une actvté de codage d'éléments du PIM par un expert (cf. 4..3). Dans l'enchaînement de transformatons de modèle précédent, les deux transformatons de modèles peuvent être contrantes par deux PDM représentant deux modèles dfférents des préconsatons des urbanstes. Un enchaînement de transformatons de modèles utlsé pour les actvtés d'archtecture de la démarche EA4UP llustre dans la Fgure 59 la successon d'une actvté statque par une actvté dynamque telles que ces deux actvtés soent contrantes par l'ea. 03

105 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PDM PIM statque Expertse PSM statque PIM dynamque PDM 2 Automatsaton PSM dynamque Fgure 59 : Codage d'expert et transformaton automatque L'enchaînement de transformatons de modèle est le suvant : - La transformaton est un codage du PIM statque avec les éléments du PDM. Ce codage réalsé par un expert permet d'obtenr un PSM statque en respectant une contrante décrte par des règles d'urbansme, - la 2 transformaton est une transformaton automatque du PIM dynamque en un PSM dynamque avec une contrante mplémentée à partr de règles d'urbansme et par un PDM. Une llustraton de ce prncpe est l'actvté de concepton automatsée des îlots et des voes fonctonnels du 3.3. Le codage est celu des îlots fonctonnels par un type flux ou un type stock. Dans ce cas, la transformaton permet d'assocer un ou pluseurs types décrt dans PDM à chaque îlot fonctonnel du PIM statque. La seconde transformaton automatsée est la mse en œuvre de la Règle d'urbansme Scsson îlot mult-typé. Permettant de défnr les voes du modèle dynamque des îlots fonctonnels. Le modèle PDM 2 est défn par la Règle d'urbansme Flux et stock (cf. Fgure 27). 04

106 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI 4..4 Descrpton d'ensemble de la démarche EA4UP La démarche EA4UP recouvre les macro-actvtés du processus UP et leurs dérvées sur les vues d'archtecture d'un système : - La collecte auprès du clent des exgences fonctonnelles et des exgences non fonctonnelles décrvant le système à développer ; - L'analyse des exgences fonctonnelles et des exgences non fonctonnelles du système ; - La concepton de l'archtecture fonctonnelle et de l'archtecture technque du système, - La concepton de l'archtecture applcatve du système, - L'mplémentaton du système, - Les tests fonctonnels, les tests de performance et de robustesse du système. Deux collaborateurs contrbuent à la démarche EA4UP décrte dans la Fgure 60 : - la MOA (maîtrse d'ouvrage), c'est-à-dre le clent du système à développer, - la MOE (maîtrse d'œuvre), sot l'équpe de développement du système. Fgure 60 : Macro-actvtés de la démarche EA4UP Les enchaînements des macro-actvtés de concepton d'une archtecture sont conformes aux nterdépendances des vues d'archtecture représentée dans la Fgure

107 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Une actvté est extrate d'une macro-actvté dans le Tableau par rapport à : - sa vue,.e. fonctonnelle, technque ou applcatve, - son aspect,.e. statque ou dynamque, - les concepts (cf ) produts. Macro-actvté Actvté Vue Statque / Dynamque Collecte des Collecte des Fonctonnelle Statque exgences exgences fonctonnelles statques Collecte des Dynamque exgences fonctonnelles dynamques Analyse Concepton de l'archtecture fonctonnelle Concepton de l'archtecture technque Collecte des exgences non fonctonnelles Analyse fonctonnelle statque Analyse fonctonnelle dynamque Analyse technque statque Analyse technque dynamque Archtecture fonctonnelle statque Archtecture fonctonnelle dynamque des îlots Archtecture fonctonnelle dynamque des données Archtecture technque statque Archtecture technque dynamque Archtecture technque détallée Technque Fonctonnelle Technque Fonctonnelle Technque Statque et Dynamque Statque Dynamque Statque Dynamque Statque Dynamque Dynamque Statque Dynamque Statque Concepts produts Cas d'utlsaton Scénaro et Tâche Exgence non fonctonnelle Entté, Attrbut d'entté et Relaton entre enttés Interacton entre enttés Proprété technque statque Proprété technque dynamque Îlot fonctonnel et Parcelle fonctonnelle Interacton entre îlots fonctonnels et Voe fonctonnelle Donnée logque et Attrbut de donnée logque Nœud d'exécuton Protocole 06

108 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Concepton de l'archtecture applcatve Archtecture applcatve statque Archtecture applcatve dynamque des composants Archtecture applcatve dynamque des données Applcatve Statque Dynamque Dynamque Archtecture Statque applcatve détallée Implémentaton Implémentaton Applcatve Statque Test Test fonctonnel Applcatve Dynamque Test de robustesse Dynamque et de performance Tableau : Macro-actvté UP et actvtés EA4UP. Composant applcatf Interacton entre composants applcatfs et Interface applcatve Donnée physque et Attrbut de donnée physque Chaque actvté de la démarche EA4UP est détallée dans le 4.2. Les actvtés spécfques à la démarche EA4UP sont llustrées dans ce même paragraphe avec un cas d'utlsaton de servce télécom. 4.2 Démarche EA4UP fondée sur l'approche dynamque et l'ngénere des modèles Chaque actvté de la démarche EA4UP est décrte par : - son objectf, - la ou les actvtés en amont de cette actvté, - la règle d'urbansme à respecter, - un schéma de la transformaton de modèle avec son caractère automatsable ou non (cf. 4..3) et les concepts utles, - un mode de représentaton des concepts produts par l'actvté (cf. 4..4). L'llustraton de la démarche EA4UP est celle d'un servce télécom de messagere électronque. L'usage étudé est celu de la récepton d'un message électronque. Le PLU fonctonnel est celu décrt dans la Fgure 3 qu sert d'llustraton à la démarche DA4EA Collecte des exgences La collecte des exgences fonctonnelles et des exgences non fonctonnelles du système à développer est une macro-actvté sous la responsablté du clent du système développé, sot la MOA du système. L'utlsaton fonctonnelle, ou non fonctonnelle, du système est détallée dans cette macro-actvté entourée dans la Fgure 6. 07

109 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 6 : Macro-actvté de collecte des exgences dans la démarche EA4UP Collecte des exgences fonctonnelles statques L'actvté de collecte des exgences fonctonnelles statques, entourée dans la Fgure 62, a pour objectf de détaller les cas d'utlsaton du système. Fgure 62 : Actvté de collecte des exgences fonctonnelles statques 08

110 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le concept de la vue fonctonnelle produt par cette actvté est le cas d'utlsaton. Le beson de la MOA du système est décrt dans un caher des charges. L'objectf de la collecte des exgences fonctonnelles statques est de tradure ce beson en cas d'utlsaton du système par un de ses utlsateurs. Chaque cas d'utlsaton du système détalle une sére d'échanges entre l'utlsateur du système et le système offrant une valeur ajoutée à cet utlsateur. Un mode de représentaton des cas d'utlsaton est une descrpton textuelle. Le cas d'utlsaton CU-Récepton de message avec fltrage, à l'orgne de l'llustraton de la démarche EA4UP, est le suvant : L'utlsateur de la messagere électronque reçot un message. Il peut stocker le message dans sa boîte de messagere unquement s le fltrage cblant l'objet du message a un résultat négatf Collecte des exgences fonctonnelles dynamques L'actvté de collecte des exgences fonctonnelles dynamques, entourée dans la Fgure 63, recouvre la descrpton des scénaros llustrant chaque cas d'utlsaton collecté lors de l'actvté lée aux exgences fonctonnelles statques (cf ). Fgure 63 : Actvté de collecte des exgences fonctonnelles dynamques Le concept de la vue fonctonnelle produt par cette actvté est le scénaro. Une transformaton smple décrte dans la Fgure 64 est la créaton d'un ensemble de scénaros à partr de chaque cas d'utlsaton du système. Chaque scénaro représente un ensemble de résultats spécfques aux branchements condtonnels d'un cas d'utlsaton. Le rôle de l'expert est de découper chaque scénaro en tâche. La règle d'urbansme à mettre en œuvre lors de cette transformaton décrt le len entre les cas d'utlsaton collectés précédemment et les scénaros. Règle d'urbansme Collecte des exgences fonctonnelles dynamques n 7 Un scénaro est une llustraton d'un cas d'utlsaton prenant en compte des résultats pour chaque branchement condtonnel du cas d'utlsaton. 09

111 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PIM statque Expertse PSM dynamque Fgure 64 : Concepts et transformaton lés à l'actvté de collecte des exgences fonctonnelles dynamques Un mode de représentaton des scénaros est une descrpton textuelle avec un ordonnancement des tâches défnssant une nteracton entre l'utlsateur du système et le système. Pour chaque cas d'utlsaton, un ensemble de scénaros détalle l'ordonnancement des tâches. Le seul branchement condtonnel du cas d'utlsaton CU-Récepton de message avec fltrage est le résultat du fltrage du message. Il exste donc un scénaro avec un fltrage ayant un résultat postf et un scénaro avec un fltrage ayant un résultat négatf. Le scénaro SC-Fltrage négatf où le résultat du fltrage est négatf est le suvant :. L'utlsateur reçot un message 2. Le résultat du fltrage du message par rapport à son objet est négatf 3. Le message est stocké dans une boîte de messagere Le scénaro SC-Fltrage postf où le résultat du fltrage est postf est :. L'utlsateur reçot un message 2. Le résultat du fltrage du message par rapport à son objet est postf 3. La récepton du message est nterrompue La Règle d'urbansme Collecte des exgences fonctonnelles dynamques est satsfate pusque les deux scénaros sont déduts des deux résultats possbles du branchement condtonnel lé au fltrage : négatf ou postf Collecte des exgences non fonctonnelles L'actvté de collecte des exgences non fonctonnelles, entourée dans la Fgure 65, a pour objectf de spécfer les exgences non fonctonnelles du système. Fgure 65 : Actvté de collecte des exgences non fonctonnelles 0

112 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le concept de la vue technque produt par l'actvté est l'exgence non fonctonnelle. Le mode de représentaton des exgences non fonctonnelles est une défnton textuelle. Cette défnton peut être assocée à un cas d'utlsaton lors de la collecte des exgences non fonctonnelles. Les exgences non fonctonnelles dans le cadre du cas d'utlsaton CU-Récepton de message avec fltrage sont : - ENF-MMR qu stpule le nombre moyen de messages reçus par utlsateur, - ENF-TMS ndquant la talle maxmum de stockage des messages dans une boîte de messagere Analyse L'analyse fonctonnelle et l'analyse technque du système à développer consttuent une macro-actvté sous la responsablté de l'équpe de développement du système, sot la MOE. Cette macro-actvté, entourée dans la Fgure 66, nécesste néanmons de nombreux échanges avec la MOA afn de s'assurer que l'analyse répond ben aux exgences collectées. Fgure 66 : Macro-actvté d'analyse dans la démarche EA4UP Analyse fonctonnelle statque L'actvté d'analyse statque entourée dans la Fgure 67 permet de spécfer les enttés partcpantes au système et leurs relatons. Les enttés partcpantes à l'ensemble des cas d'utlsaton du système, collectés lors de l'actvté lées aux exgences fonctonnelles statques (cf ), sont détallées par attrbut. Cette actvté d'expert permet la défnton des données de la vue fonctonnelle.

113 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 67 : Actvté d'analyse fonctonnelle statque La transformaton décrte dans la Fgure 68 permet le contrôle de la cohérence de l'actvté. L'actvté d'analyse fonctonnelle statque est la transformaton par un expert d'un ensemble de cas d'utlsaton d'un système en un ensemble d'enttés défnes par des attrbuts et pouvant être relées entre elles. La règle d'urbansme lée à cette actvté permet de s'assurer de la traçablté du len entre le cas d'utlsaton du système et les enttés partcpantes à ce cas d'utlsaton. Règle d'urbansme Analyse fonctonnelle statque n 8 Une relaton spécfée entre deux enttés nécesste la partcpaton de ces enttés à au mons un même cas d'utlsaton. PIM statque Expertse PSM statque Fgure 68 : Concepts et transformaton lés à l'actvté d'analyse fonctonnelle statque Un mode de représentaton des enttés est un dagramme de classes UML stéréotypées <<entté>>. L'attrbut d'une entté est un attrbut de la classe représentant l'entté et une relaton entre enttés est une assocaton entre les classes représentant les enttés relées. 2

114 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Un exemple d'enttés partcpantes au cas d'utlsaton CU-Récepton de message avec fltrage est représenté dans le dagramme de classes UML de la Fgure 69. Fgure 69 : Illustraton des enttés de l'actvté d'analyse fonctonnelle statque Lorsqu'un message est reçu, l'applcaton de la règle de fltrage par rapport à l'objet du message permet de valorser l'ndcateur de fltrage du message. S l'ndcateur est négatf, alors le message est stocké dans une boîte de messagere dont la talle augmente. La Règle d'urbansme Analyse fonctonnelle statque est satsfate pusque toutes les enttés partcpent au même cas d'utlsaton CU-Récepton de message avec fltrage Analyse fonctonnelle dynamque L'actvté d'analyse fonctonnelle dynamque, entourée dans la Fgure 70, permet de spécfer les nteractons nstancées entre enttés ssues de l'analyse fonctonnelle statque (cf ). L'nstancaton est lée au déroulement de scénaros collectés lors de l'actvté lée aux exgences fonctonnelles dynamques (cf ). Fgure 70 : Actvté d'analyse fonctonnelle dynamque 3

115 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le concept de la vue fonctonnelle résultant de l'actvté d'analyse fonctonnelle dynamque est l'nteracton entre enttés. La transformaton décrte dans la Fgure 7 permet de produre les nteractons entre enttés à partr d'une actvté de codage (cf. 4..3). L'expert code chaque tâche des scénaros avec les relatons entre enttés spécfées en analyse fonctonnelle statque. La règle d'urbansme lée à cette actvté permet de soulgner la cohérence de l'analyse fonctonnelle dynamque avec l'analyse fonctonnelle statque. Règle d'urbansme Analyse fonctonnelle dynamque n 9 Toutes les nteractons entre deux enttés, nstancées lors du déroulement d'un scénaro llustrant l'usage d'un système, nécesstent une relaton entre les deux enttés. PSM statque PIM dynamque Expertse PSM dynamque Fgure 7 : Concepts et transformaton lés à l'actvté d'analyse fonctonnelle dynamque Un mode de représentaton des nteractons entre enttés nstancées lors d'un scénaro de l'utlsaton d'un système est le dagramme de séquence UML. La représentaton de la successon temporelle d'nteractons et la représentaton de la dépendance d'nteractons respecte la Sémantque UML Approche dynamque et dagramme de séquence (cf. 2..5). Les nteractons sont de type requête ou de type réponse. La défnton du type d'une nteracton entre enttés est analogue à celle des nteractons entre îlots fonctonnels du 3.2. Défnton : une nteracton entre nstances d'enttés est : - de type requête s l'nteracton est une demande, ou s l'nteracton correspond à l'émsson de paramètres d'entrée d'une requête, - de type réponse s l'nteracton est une réponse à une demande ou s l'nteracton correspond à l'émsson de paramètres de sorte d'une requête. 4

116 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Dans l'llustraton chose, les tâches du scénaro SC-Fltrage négatf sont représentées dans le dagramme de séquence de la Fgure 72. Les paramètres d'entrée et de sorte d'une nteracton sont ndqués entre parenthèses, respectvement, après le mot clé n et après le mot clé out. Ces paramètres sont les attrbuts des enttés nstancées.. L'utlsateur reçot un message 2. Le résultat du fltrage du message par rapport à son objet est négatf 3. Le message est stocké dans une boîte de messagere Fgure 72 : Illustraton des nteractons de l'actvté d'analyse fonctonnelle dynamque 5

117 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le len entre chaque tâche du scénaro et les enttés sont les suvants : - la tâche du scénaro L'utlsateur reçot un message et o l'entté Message et son attrbut Date de récepton, - la tâche 2 du scénaro Le résultat du fltrage du message par rapport à son objet est négatf et o l'entté Message et son attrbut Indcateur de fltrage o l'entté Règle de fltrage et son attrbut Lbellé, - la tâche 3 du scénaro Le message est stocké dans une boîte de messagere et o l'entté Message et son attrbut Date de stockage o l'entté Boîte de messagere et son attrbut Talle de stockage. La Règle d'urbansme Analyse fonctonnelle dynamque est satsfate pusque : - les nteractons entre les nstances des enttés Boîte de messagere et Message sont conformes à la relaton est stocké dans entre ces enttés, - les nteractons entre les nstances des enttés Message et Règle de fltrage sont conformes à la relaton est fltré par entre ces enttés Analyse technque statque L'actvté d'analyse technque statque, entourée dans la Fgure 73, permet d'assocer une exgence non fonctonnelle collectée (cf ) à un élément spécfé lors de l'analyse fonctonnelle statque (cf ). Fgure 73 : Actvté d'analyse technque statque Le concept défn par l'assocaton d'une exgence non fonctonnelle avec une entté ou une relaton entre enttés est une proprété technque statque. Ce concept de la vue technque décrt dans la Fgure 74 permet de précser les éléments spécfés durant l'analyse fonctonnelle statque qu sont mpactés par une exgence non fonctonnelle. 6

118 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PSM statque PIM statque Expertse PSM statque Fgure 74 : Concepts et transformaton lés à l'actvté d'analyse technque statque Un mode de représentaton du concept de proprété technque statque est une descrpton textuelle. Le Tableau 2 représente les exgences non fonctonnelles assocées aux attrbuts d'entté ou aux relatons entre enttés pour le cas d'utlsaton CU-Récepton de message avec fltrage. Chaque proprété technque statque est un couple formé par un élément d'analyse fonctonnelle statque et une exgence non fonctonnelle collectée. Élément d'analyse fonctonnelle statque Exgence non Entté Attrbut d'entté Len entre enttés fonctonnelle Message Date de récepton ENF-MMR Indcateur de ENF-MMR fltrage Boîte de messagere Talle de stockage ENF-TMS Message Boîte de messagere est stocké dans ENF-TMS Tableau 2 : Illustraton des proprétés technques statques de l'actvté d'analyse technque statque. Un exemple de proprété technque statque est le couple (Date de récepton, ENF- MMR). L'exgence ENF-MMR du nombre moyen de messages reçus mpacte en effet l'attrbut Date de récepton de l'entté Message. Un autre exemple est le couple (est stocké dans, ENF-TMS) qu décrt le len entre - l'exgence ENF-TMS ndquant la talle maxmum de la boîte de messagere, et - la relaton est stocké dans qu spécfe le stockage d'un message dans cette boîte. 7

119 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Analyse technque dynamque L'actvté d'analyse technque dynamque, entourée dans la Fgure 75, permet d'assocer des exgences non fonctonnelles avec des nteractons de type requête nstancées lors du déroulement de scénaros de cas d'utlsaton du système (cf ). L'assocaton est dédute de l'analyse technque statque (cf ) où les attrbuts des enttés et les relatons entre enttés sont assocés à des exgences non fonctonnelles. Une nteracton de type requête entre nstances d'enttés dot en effet être conforme à une relaton entre enttés d'après la Règle d'urbansme Analyse fonctonnelle dynamque. De plus, le paramètre de sorte d'une nteracton de type requête est l'nstancaton d'au mons un attrbut d'une entté. Fgure 75 : Actvté d'analyse technque dynamque Le concept de la vue technque résultant de l'actvté est la proprété technque dynamque. La transformaton décrte dans la Fgure 76 permet de produre les proprétés technques dynamques. Cette transformaton a l'ensemble des proprétés statques en entrée et est contrante par les nteractons entre enttés défnes lors de l'analyse fonctonnelle dynamque. La règle d'urbansme lée à cette actvté permet de soulgner la cohérence de l'analyse technque statque avec l'analyse technque dynamque. Règle d'urbansme Analyse technque dynamque n 0 Toutes proprétés technques dynamques lée à une nteracton entre enttés de type requête est assocée : - à une proprété technque statque lée à une relaton entre les enttés de l'nteracton, ou - à une proprété technque statque lée à un attrbut de l'entté cble de l'nteracton. 8

120 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PSM dynamque PIM statque Expertse PSM dynamque Fgure 76 : Concepts et transformaton lés à l'actvté d'analyse technque dynamque Un mode de représentaton du concept de proprété technque dynamque est une descrpton textuelle ajoutée au dagramme de séquence UML qu représente les nteractons entre nstances d'enttés. 9

121 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le dagramme de séquence de la Fgure 77 représente le scénaro SC-Fltrage négatf auquel sont ntégrées l'exgence non fonctonnelle ENF-MMR du nombre moyen de messages reçus et l'exgence non fonctonnelle ENF-TMS de la talle maxmale de stockage de messages. ENF-MMR ENF-MMR ENF-TMS ENF-TMS Fgure 77 : Illustraton des proprétés technques dynamques de l'actvté d'analyse technque dynamque 20

122 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Un exemple de proprété technque dynamque est l'assocaton entre la proprété technque statque (Date de récepton, ENF-MMR) et l'nteracton de type requête Recevor un message. Une autre proprété technque dynamque est l'assocaton entre la proprété technque statque (est stocké dans, ENF-TMS) et l'nteracton de type requête Stocker un message. La Règle d'urbansme Analyse technque dynamque (cf ) est satsfate pusque toutes les proprétés technques dynamques sont assocées drectement à des proprétés technques statques Concepton de l'archtecture fonctonnelle La concepton de l'archtecture fonctonnelle du système est une macro-actvté sous la responsablté de l'équpe de développement, sot la MOE du système. Cette macroactvté, entourée dans la Fgure 78, nécesste que le système sot analysé. Le PLU fonctonnel conçu par les urbanstes fonctonnels contrant les actvtés d'archtecture fonctonnelle. Fgure 78 : Macro-actvté de concepton de l'archtecture fonctonnelle dans la démarche EA4UP Archtecture fonctonnelle statque L'actvté de concepton de l'archtecture fonctonnelle statque d'un système, entourée dans la Fgure 79, a pour objectf de concevor les îlots de la vue fonctonnelle du système qu réalsent les éléments spécfés lors de l'analyse fonctonnelle statque (cf ). Les îlots sont sot extrats du PLU fonctonnel valdé (cf. 3..2), sot créés s nécessare. La vue fonctonnelle d'éléments à réutlser du SI dot auss être comparée avec la vue fonctonnelle du système lors de cette actvté. 2

123 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 79 : Actvté d'archtecture fonctonnelle statque Le concept prncpal de l'actvté d'archtecture fonctonnelle statque est la parcelle fonctonnelle représentée dans la Fgure 80. L'expert code chaque attrbut d'entté, ou chaque relaton entre enttés, avec une ou pluseurs parcelles fonctonnelles. Ce codage sgnfe qu'une donnée produte par cette ou ces parcelles fonctonnelles est extrate de l'attrbut ou de la relaton codée. Chacune de ces parcelles est contenue dans un îlot fonctonnel. L'îlot fonctonnel est sot ssu du PLU fonctonnel afn de favorser la réutlsaton de tout ou parte du système (cf. 4..), sot spécfque au système. La règle d'urbansme assocée à l'actvté d'archtecture fonctonnelle statque assure la cohéson avec l'archtecture du PLU fonctonnel. La cohéson est due à l'adéquaton de chaque parcelle avec le typage de l'îlot qu la content. Règle d'urbansme Archtecture fonctonnelle statque n Chaque parcelle fonctonnelle codant un attrbut d'une entté ou une relaton entre enttés dot être contenue : - dans un îlot fonctonnel de type flux, suvant la dépendance de la durée de ve d'une nstance de la parcelle par rapport au processus supporté (cf. 3.3.), - dans un îlot fonctonnel de type stock suvant l'ndépendance de la durée de ve d'une nstance de la parcelle par rapport au processus supporté (cf. 3.3.). 22

124 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PDM Expertse PIM statque PSM statque Fgure 80 : Concepts et transformaton lés à l'actvté d'archtecture fonctonnelle statque La contrante de l'assocaton d'une parcelle fonctonnelle et d'un îlot fonctonnel qu le content est que chaque parcelle dot appartenr de façon exclusve : - sot à un îlot fonctonnel unque conçu dans le PLU fonctonnel, - sot à un îlot spécfque au système développé. Le mode de représentaton des îlots fonctonnels et de leurs parcelles fonctonnelles est le dagramme de classes UML décrt dans le 3.2 avec le stéréotype défn dans le

125 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI L'expert code les éléments de l'analyse fonctonnelle statque avec les parcelles du PLU fonctonnel représenté dans la Fgure 3 ou avec des parcelles fonctonnelles spécfques au servce. Le Tableau 3 comprend les résultats de ce codage. Élément d'analyse fonctonnelle statque Entté Attrbut d'entté Len entre enttés Message Date de récepton Indcateur de fltrage Parcelle fonctonnelle du PLU Recevor un message Fltrer un message par rapport à l'objet du message Parcelle fonctonnelle spécfque Date de Stocker un stockage message Boîte de Talle de messagere stockage Règle de fltrage Lbellé Consulter une règle de fltrage de message Message est stocké Stocker un Boîte de dans message messagere Message est fltré par Fltrer un Règle de fltrage message par rapport à l'objet du message Tableau 3 : Illustraton du codage des éléments d'analyse fonctonnelle statque par les parcelles fonctonnelles du système. Le chox de concepton de l'archtecte fonctonnel est c de ne pas créer de nouvel îlot fonctonnel contenant les parcelles fonctonnelles non décrtes dans le PLU fonctonnel. Les parcelles fonctonnelles spécfques sont regroupées avec des parcelles fonctonnelles du PLU fonctonnellement proches. La parcelle Stocker un message est, par exemple, proche fonctonnellement de la parcelle Recevor un message. La parcelle fonctonnelle Stocker un message est donc ncluse par l'expert dans l'îlot fonctonnel Récepton d'un message. Il en est de même de la parcelle fonctonnelle du PLU fonctonnel Créer les règles de fltrage de message et de la parcelle fonctonnelle spécfque du servce Consulter une règle de fltrage de message qu sont assez proches fonctonnellement pour être regroupées dans l'îlot fonctonnel Sécurté de la messagere Gérer les règles de fltrage. Les classes UML de la Fgure 8 représente les îlots fonctonnels et les parcelles fonctonnelles réalsant les éléments d'analyse fonctonnelle statque qu partcpent au cas d'utlsaton du système CU-Récepton de message avec fltrage. 24

126 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 8 : Illustraton des îlots fonctonnels de l'actvté d'archtecture fonctonnelle statque La Règle d'urbansme Archtecture fonctonnelle statque est respectée dans cette llustraton pusque - la parcelle fonctonnelle Stocker un message dot appartenr à un îlot fonctonnel de type flux et, - la parcelle fonctonnelle Consulter une règle de fltrage de message dot appartenr à un îlot fonctonnel de type stock. De plus, les parcelles fonctonnelles conçues correspondent à la vue fonctonnelle de deux enablers : - l'enabler Stockage pour la parcelle fonctonnelle Stocker un message, - l'enabler Messagere pour toutes les autres parcelles Archtecture fonctonnelle dynamque des îlots L'actvté de concepton de l'archtecture fonctonnelle dynamque des îlots d'un système conçus durant l'actvté d'archtecture fonctonnelle statque (cf ), entourée dans la Fgure 82, a pour objectf de concevor les nteractons entre îlots de la vue fonctonnelle du système. Ces nteractons entre îlots réalsent un scénaro spécfé en analyse fonctonnelle dynamque (cf ). Les nteractons entre îlots sont sot conformes au PLU fonctonnel valdé (cf. 3..2), sot créées lorsqu'elles ne sont pas décrtes dans le PLU fonctonnel. 25

127 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 82 : Actvté d'archtecture fonctonnelle dynamque des îlots Le concept prncpal de l'actvté d'archtecture fonctonnelle dynamque des îlots décrt dans la Fgure 85 est l'nteracton entre îlots fonctonnels. Cette nteracton est nstancée lors du déroulement d'un scénaro d'un cas d'utlsaton du système. Le second concept dédut mmédatement des nteractons entre îlots fonctonnels est la voe fonctonnelle entre ces îlots. L'archtecture fonctonnelle dynamque des îlots est une transformaton automatsée conforme à l'enchaînement décrt dans la Fgure 59. Le codage est celu des attrbuts des enttés et des relatons entre enttés par les parcelles fonctonnelles lors de l'actvté d'archtecture fonctonnelle statque (cf ). En complément des parcelles fonctonnelles conçues lors de l'archtecture fonctonnelle statque, l'exstence et l'orentaton des voes du PLU fonctonnel contragnent la transformaton. La règle d'urbansme assocée à l'actvté d'archtecture fonctonnelle dynamque des îlots assure - l'algnement des nteractons entre nstances de voes fonctonnelles avec une nteracton entre nstances d'enttés, - la cohérence des nteractons entre îlots fonctonnels avec les voes fonctonnelles conçues dans le PLU fonctonnel. Défnton : Une nteracton entre deux nstances d'îlots fonctonnels est algnée avec une nteracton entre nstances d'enttés s : - les deux îlots fonctonnels codent une même entté qu est la source ou la cble d'une nteracton, - l exste une nteracton entre une nstance d'une entté codée par un des deux îlots fonctonnels de l'nteracton et une nstance d'une entté codée par l'autre îlot fonctonnel. 26

128 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Un exemple smple d'algnement d'nteractons entre îlots fonctonnel avec des nteractons entre enttés est décrt dans la Fgure 83 pour le codage et dans la Fgure 84 pour l'algnement des nteractons. Les dagrammes de séquence nstancant des enttés et des îlots fonctonnels représentent le même scénaro du cas d'utlsaton CU. Codage de l'entté E par les îlots fonctonnels I et I2 Codage de l'entté E2 par l'îlot fonctonnel I3 Fgure 83 : Algnement d'nteractons dans la règle d'urbansme lée à l'archtecture fonctonnelle dynamque des îlots Codage 27

129 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Algnement des nteractons Algnement des nteractons Algnement des nteractons Fgure 84 : Algnement d'nteractons dans la règle d'urbansme lée à l'archtecture fonctonnelle dynamque des îlots Algnement des nteractons 28

130 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI L'nteracton InteractonÎlots2 entre les nstances des îlots fonctonnels I et I2 qu codent la même entté E est algnée par défnton avec l'nteracton InteractonEnttés2 entre les nstances des enttés E et E2 pusque I et I2 codent E. Toujours par défnton, - l'nteracton InteractonÎlots3 entre les nstances des îlots fonctonnels I2, qu code l'entté E, et I3, qu code l'entté E2 est algnée avec l''nteracton InteractonEnttés2, - l'nteracton InteractonÎlots4 entre les nstances des îlots fonctonnels I, qu code l'entté E, et I3, qu code l'entté E2 est algnée avec l''nteracton InteractonEnttés2. Règle d'urbansme Archtecture fonctonnelle dynamque des îlots n 2 Chaque nteracton entre nstances d'îlots fonctonnels dot : - respecter la Règle d'urbansme Interactons et voes (cf. 3.2) pour les voes entre îlots extrats du PLU fonctonnel, - ntégrer la Règle d'urbansme Flux et stock (cf. 3.3.) lorsqu'elle est de type requête, - ne pas créer de cycle dans le modèle des voes fonctonnelles lorsqu'elle est de type requête, - être algnée avec une nteracton entre nstances d'enttés. PSM statque PDM PIM dynamque Automatsaton PSM dynamque Fgure 85 : Concepts et transformaton lés à l'actvté d'archtecture fonctonnelle dynamque des îlots 29

131 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI D'après la Règle d'urbansme Interactons et voes (cf. 3.2), l est mmédat de dédure les voes entre les îlots fonctonnels, qu'elles soent extrates du PLU ou non, à partr des nteractons conçues entre îlots fonctonnels. Le mode de représentaton des nteractons entre nstances d'îlots fonctonnels est le dagramme de séquence UML. Chaque nteracton est lbellée par le nom de la parcelle fonctonnelle nstancée. La représentaton de la successon temporelle d'nteractons et de la dépendance d'nteractons respecte la Sémantque UML Approche dynamque et dagramme de séquence (cf. 2..5). Le mode de représentaton des voes fonctonnelles sont des dépendances stéréotypées <<dépend de>> dans le dagramme de classes UML des îlots fonctonnels décrt dans le

132 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Dans la Fgure 86, le dagramme de séquence composé d'nteractons entre nstances d'îlots fonctonnels représente le scénaro SC- Fltrage négatf. Ce dagramme est le résultat de la transformaton du dagramme de séquence composé d'nteractons entre enttés (cf. Fgure 72). Le codage des éléments d'analyse fonctonnelle statque représenté dans le Tableau 3 permet l'automatsaton de cette transformaton. Fgure 86 : Illustraton des nteractons entre îlots fonctonnels de l'actvté d'archtecture fonctonnelle dynamque des îlots 3

133 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI La Règle d'urbansme Archtecture fonctonnelle dynamque des îlots est respectée pusque chaque nteracton entre nstances d'îlots fonctonnels est algnée avec une ou pluseurs nteractons entre nstances d'enttés spécfée en analyse fonctonnelle dynamque : - l'nteracton entre nstances d'îlots fonctonnels Recevor un message est algnée avec l'nteracton entre nstances d'enttés du même nom, - l'nteracton entre îlots fonctonnels Fltrer un message par rapport à l'objet du message est algnée avec l'nteracton entre nstances d'enttés Fltrer un message, - l'nteracton entre nstances d'îlots fonctonnels Consulter les règles de fltrage de message est algnée avec l'nteracton entre nstances d'enttés Chercher la règle de fltrage, - l'nteracton entre nstances d'îlots fonctonnels Stocker un message est algnée avec l'nteracton entre nstances d'enttés Mettre à jour la boîte de messagere et avec l'nteracton entre nstances d'enttés Stocker un message. De plus les Règle d'urbansme Interactons et voes (cf. 3.2) pour les voes entre îlots extrats du PLU fonctonnel et la Règle d'urbansme Flux et stock (cf. 3.3.) pour les nteractons de type requête sont respectées : - l'nteracton de type requête entre nstances d'îlots fonctonnels Consulter les règles de fltrage de message est orentée de l'îlot fonctonnel de type flux Sécurté de la messagere Fltrage de message vers l'îlot fonctonnel de type stock Sécurté de la messagere Gérer les règles de fltrage. Les voes fonctonnelles cohérentes avec ces nteractons entre nstances d'îlots fonctonnels ne consttuent aucun cycle. Ces voes satsfont de plus la Règle d'urbansme Interactons et voes (cf. 3.2). Le modèle d'îlots fonctonnels est représenté dans la Fgure 87. Fgure 87 : Illustraton des voes fonctonnelles de l'actvté d'archtecture fonctonnelle dynamque des îlots Pour ce scénaro SC-Fltrage négatf, aucun autre îlot fonctonnel que ceux décrts dans le PLU fonctonnel n'est nécessare et seule la voe de l'îlot fonctonnel Sécurté de la messagere Fltrage de message vers l'îlot fonctonnel Sécurté de la messagere Gérer les règles de fltrage est utle. 32

134 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Archtecture fonctonnelle dynamque des données L'actvté de concepton de l'archtecture fonctonnelle dynamque des données d'un système, entourée dans la Fgure 88, a pour premer objectf de concevor les attrbuts des données logques. Ceux-c sont les paramètres de sorte des nteractons entre nstances d'îlots fonctonnels décrtes lors de l'actvté d'archtecture dynamque des îlots (cf ). Les attrbuts des données logques sont : - extrats des attrbuts des enttés décrts en analyse fonctonnelle dynamque (cf ), - les paramètres de sorte des nteractons, de type requête, entre nstances d'enttés. Le second objectf est de défnr les données logques à partr des attrbuts. Le respect de la Règle d'urbansme Relaton de dépendance entre données (cf. 4..2) sgnfe que les voes fonctonnelles conçues lors de l'actvté d'archtecture dynamque des îlots peuvent évoluer lors de l'actvté d'archtecture fonctonnelle dynamque des données. Fgure 88 : Actvté d'archtecture fonctonnelle dynamque des données Le premer concept obtenu lors de l'actvté d'archtecture fonctonnelle dynamque des données est l'attrbut d'une donnée logque. L'attrbut est en effet un paramètre d'entrée ou de sorte d'une ou pluseurs nteractons entre nstances d'îlots fonctonnels. Le second concept dédut mmédatement des attrbuts est la donnée logque regroupant des attrbuts. Le derner concept est celu de voe entre îlots fonctonnels dont la conformté aux relatons de dépendance entre données est stpulée dans la Règle d'urbansme Relaton de dépendance entre données (cf. 4..2). L'archtecture fonctonnelle dynamque des données est la transformaton décrte dans la Fgure 89 des attrbuts d'enttés et des paramètres d'entrée ou de sorte des nteractons entre enttés en un modèle de données logques. La règle d'urbansme assocée à l'actvté d'archtecture fonctonnelle dynamque des données assure la cohérence du modèle des données logques avec le modèle des îlots fonctonnels. 33

135 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI La défnton d'une relaton de dépendance entre données logques est dédute de la défnton d'une relaton de dépendance entre attrbuts de données logques. Défnton : Deux attrbuts, A et A 2, de données logques ont une relaton de dépendance telle que A dépende de A 2. - s A 2 est le paramètre d'entrée et A est le paramètre de sorte d'une nteracton de type requête entre nstances d'îlots fonctonnels dans un dagramme de séquence UML, ou, - s A 2 est le paramètre de sorte d'une nteracton de type requête entre nstances d'îlots fonctonnels succédant drectement à une nteracton de type requête entre nstances d'îlots fonctonnels ayant pour paramètre de sorte A dans un dagramme de séquence UML. Défnton : Deux données logques sont en relaton de dépendance s au mons un attrbut d'une des données logques est en relaton de dépendance avec au mons un attrbut de l'autre donnée logque. La Règle d'urbansme Archtecture fonctonnelle dynamque des données permet de vérfer la cohérence du modèle de données avec le modèle des îlots fonctonnels. Règle d'urbansme Archtecture fonctonnelle dynamque des données n 3 - Tous les attrbuts d'une même donnée logque sont produts par un seul îlot fonctonnel conformément à la Règle d'urbansme Donnée produte et îlot fonctonnel décrte dans le ; - Deux attrbuts en relaton de dépendance et produts par le même îlot fonctonnel peuvent être regroupés dans une même donnée logque, - Chaque relaton de dépendance entre données logques est conforme à une voe entre îlots fonctonnels (cf. Règle d'urbansme Relaton de dépendance entre données du 4..2). PSM dynamque PIM dynamque Automatsaton PSM dynamque Fgure 89 : Concepts et transformaton lés à l'actvté d'archtecture fonctonnelle dynamque des données 34

136 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le mode de représentaton des données logques est le dagramme de classes UML stéréotypées <<donnée logque>> et le dagramme de séquence UML des nteractons entre nstances d'îlots fonctonnels où les données logques et leurs attrbuts représentent les paramètres d'entrée ou de sorte des nteractons. La donnée logque et son attrbut sont séparés par le caractère "/". Le mode de représentaton des voes fonctonnelles reste celu des dépendances stéréotypées <<dépend de>> dans le dagramme de classes UML des îlots fonctonnels décrt dans le 3.2. Le dagramme de séquence des nteractons entre nstances d'îlots fonctonnels représentant le scénaro SC-Fltrage négatf de la Fgure 86 est complété par les paramètres d'entrée et de sorte. Le dagramme de séquence complet est décrt dans la Fgure 90. Les paramètres des nteractons de type requête sont les attrbuts des données logques qu résultent de la transformaton des paramètres d'entrée et de sorte des nteractons entre enttés représentés dans la Fgure

137 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 90 : Illustraton des données logques de l'actvté d'archtecture fonctonnelle dynamque des données 36

138 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le modèle de données logques résultant de la transformaton est consttué de : - la donnée logque Date de récepton défne par l'attrbut Date de récepton, - la donnée logque Indcateur de fltrage défne par l'attrbut Indcateur de fltrage, - la donnée logque Règle de fltrage défne par l'attrbut Règle de fltrage, - la donnée logque Stockage de message défne par les attrbuts Talle de stockage et Date de stockage. L'llustraton de la de la Fgure 90 soulgne le respect de la Règle d'urbansme Archtecture fonctonnelle dynamque des données. La producton d'une donnée logque par un îlot fonctonnel est représentée par un len de dépendance stéréotypé <<produt>>. - l'attrbut Date de récepton est produt par l'îlot fonctonnel Récepton d'un message, - l'attrbut Indcateur de fltrage est produt par l'îlot fonctonnel Sécurté de la messagere Fltrage de message, - l'attrbut Règle de fltrage est produt par l'îlot fonctonnel Sécurté de la messagere Gérer les règles de fltrage, - les attrbuts Talle de stockage et Date de stockage sont produts par l'îlot fonctonnel Récepton d'un message, - les attrbuts Talle de stockage et Date de stockage qu ont une relaton de dépendance dans le dagramme de séquence représentant le scénaro SC- Fltrage négatf sont regroupés dans la donnée logque Stockage de message, - la relaton de dépendance de la donnée logque Stockage de message vers la donnée logque Indcateur de fltrage est conforme à la voe de l'îlot fonctonnel Récepton d'un message vers l''îlot fonctonnel Sécurté de la messagere Fltrage de message (relatons entourées et relées dans l'llustraton), - la relaton de dépendance de la donnée logque Indcateur de fltrage vers la donnée logque Règle de fltrage est conforme à la voe de l'îlot fonctonnel Sécurté de la messagere Fltrage de message vers l''îlot fonctonnel Sécurté de la messagere Gérer les règles de fltrage (relatons entourées et relées dans l'llustraton) Concepton de l'archtecture technque La concepton de l'archtecture technque du système est une macro-actvté sous la responsablté de l'équpe de développement, sot la MOE du système. Cette macroactvté, entourée dans la Fgure 9, nécesste que le système sot analysé et que l'archtecture fonctonnelle sot conçue. De plus, les préconsatons fates par les urbanstes technques contragnent cette actvté. Comme pour l'urbansme fonctonnel et son PLU, l'objectf est de sélectonner suvant des crtères de performance et des crtères économques les nœuds d'exécuton et les protocoles de la vue technque (cf ) à utlser lors du développement d'un système du SI. L'actvté d'urbansme technque n'est pas détallée c méthodologquement. L'évènement de valdaton des préconsatons technques est néanmons ntégré à la descrpton des actvtés d'archtecture technque. Les nœuds d'exécuton décrvant la vue technque d'éléments à réutlser du SI sont étudés lors de la macro-actvté de concepton de l'archtecture technque. Cette étude permet de s'assurer de la vablté technque de l'élément à réutlser tel qu'l est détecté lors de l'actvté d'archtecture fonctonnelle statque. 37

139 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 9 : Macro-actvté de concepton de l'archtecture technque dans la démarche EA4UP Archtecture technque statque L'actvté de concepton de l'archtecture technque statque d'un système, entourée dans la Fgure 92, a pour objectf de concevor les nœuds d'exécuton satsfasant les proprétés technques statques du système spécfées en analyse technque statque (cf ). Cette concepton des nœuds d'exécuton dot a pror respecter les préconsatons de l'urbansme technque. Une préconsaton de nœud d'exécuton est celle d'un type de nœud, par exemple, un nœud d'exécuton de type serveur IBM x335 ou un OS Wndows 200 AS SP3. Une préconsaton d'un type de serveur ou d'un type d'os (Operatng System) permet de dmnuer le coût d'achat auprès des fournsseurs, mas auss de proposer une assstance nterne performante aux utlsateurs des nœuds d'exécutons recommandés. Le nœud d'exécuton peut consttuer auss la vue technque d'un élément réutlsable du SI détecté lors de l'actvté d'archtecture fonctonnelle statque (cf ). 38

140 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 92 : Actvté d'archtecture technque statque L'expert sélectonne parm les nœuds d'exécuton, dont le type est préconsé par l'urbanste technque, ceux qu satsfont les proprétés technques statques du système (cf. Fgure 93). Lorsque les proprétés technques statques l'exgent, un type de nœud d'exécuton non préconsé peut être chos par l'archtecte technque du système. Les nœuds d'exécuton du système sont cohérents avec certans îlots fonctonnels lorsque ceux-c décrvent la vue fonctonnelle d'un élément à réutlser du SI. 39

141 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PSM statque PDM PIM statque Expertse PSM statque Fgure 93 : Concepts et transformaton lés à l'actvté d'archtecture technque statque Un mode de représentaton des nœuds d'exécuton est celu des nœuds du dagramme de déploement UML. Dans le cas partculer d'un servce télécom, un nœud d'exécuton peut être la vue technque d'un enabler tels que défn par l'oma (Open Moble Allance) [OMA, 2005]. Un enabler a en effet pour vocaton d'être réutlsé lors de la concepton de servces télécom. Les éléments technques composant la vue technque d'un enabler répondent à cette exgence. Pour les proprétés technques statques décrtes dans le Tableau 2, le chox de l'archtecte technque représenté dans la Fgure 94 confrme le résultat de l'archtecture fonctonnelle statque quant aux enablers réutlsables : - l'enabler Messagere qu satsfat l'assocaton de l'exgence non fonctonnelle du nombre moyen de messages reçus ENF-MMR avec les attrbuts d'entté Date de récepton et Indcateur de fltrage, - l'enabler Stockage qu satsfat l'assocaton de l'exgence non fonctonnelle de la talle maxmum de stockage ENF-TMS avec l'attrbut d'entté Talle de stockage et le len entre enttés est stocké dans. Fgure 94 : Illustraton des nœuds d'exécuton de l'actvté d'archtecture technque statque 40

142 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Archtecture technque dynamque L'actvté de concepton de l'archtecture technque dynamque d'un système, entourée dans la Fgure 95, a pour objectf de concevor les protocoles satsfasant les proprétés technques dynamques du système. Ces proprétés sont spécfées en analyse technque dynamque (cf ). La concepton des protocoles relant les nœuds d'exécuton conçus lors de l'actvté d'archtecture technque statque (cf ) dot respecter les préconsatons de l'urbansme technque. Une préconsaton de protocole est, par exemple, un protocole de type FTP ou de type SIP. Ce chox commun d'un type de protocole pour le développement de systèmes d'un même SI permet d'assurer la cohérence globale des lens de communcaton entre nœuds d'exécuton du SI. Fgure 95 : Actvté d'archtecture technque dynamque L'expert sélectonne parm les protocoles, dont le type est préconsé par l'urbansme technque, ceux qu satsfont les proprétés technques dynamques du système (cf. Fgure 96). Les protocoles sélectonnés dovent être compatbles avec les nœuds d'exécuton, conçus lors de l'actvté d'archtecture technque statque, qu les relent. Lorsque les proprétés technques dynamques l'exgent, un type de protocole non préconsé peut être chos par l'archtecte technque du système. 4

143 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PSM statque PDM PIM dynamque Expertse PSM dynamque Fgure 96 : Concepts et transformaton lés à l'actvté d'archtecture technque dynamque Un mode de représentaton des protocoles est celu des lens de communcaton des dagrammes de déploement UML. Pour les proprétés technques dynamques décrtes dans le dagramme de séquence de la Fgure 77, le chox de l'archtecte technque représenté dans la Fgure 97 s'est porté sur - Le protocole FTP qu satsfat l'exgence non fonctonnelle ENF-TMS assocée à l'nteracton de type requête Stocker un message ayant pour source l'entté Boîte de messagere assocée au nœud d'exécuton Enabler Stockage et pour cble l'entté Message assocée au nœud d'exécuton Enabler Messagere. Fgure 97 : Illustraton d'un protocole de l'actvté d'archtecture technque dynamque 42

144 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Archtecture technque détallée L'actvté d'archtecture technque détallée, entourée dans la Fgure 98, permet de détaller les nœuds d'exécuton conçus lors de l'actvté d'archtecture technque statque (cf ) ans que les protocoles conçus lors de l'actvté d'archtecture technque dynamque (cf ). Fgure 98 : Actvté d'archtecture technque détallée L'actvté d'archtecture technque détallée n'est pas explctée c car elle ne comporte pas de spécfcté dans la démarche EA4UP Concepton de l'archtecture applcatve La concepton de l'archtecture applcatve du système est une macro-actvté sous la responsablté de l'équpe de développement, sot la MOE du système. Cette macroactvté, entourée dans la Fgure 99, nécesste que le système sot fonctonnellement et technquement archtecturé. L'objectf de l'archtecture applcatve est la concepton de composant applcatfs et de leurs nterfaces réalsant l'archtecture fonctonnelle du système (cf ) et étant déployée sur l'archtecture technque du système (cf ). 43

145 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 99 : Macro-actvté de concepton de l'archtecture applcatve dans la démarche EA4UP La transformaton pour réalser les actvtés de la macro-actvté d'archtecture applcatve est plus classque par rapport à l'approche MDA. En effet, l'expert transforme un modèle d'archtecture fonctonnelle en un modèle d'archtecture applcatve en respectant une contrante représentée par un modèle d'archtecture technque. Le PDM modélsant les éléments applcatfs à réutlser dans le SI est ajouté à cette contrante Archtecture applcatve statque L'actvté de concepton de l'archtecture applcatve statque d'un système, entourée dans la Fgure 00, a pour objectf de concevor les composants applcatfs qu réalsent les îlots conçus lors de l'archtecture fonctonnelle statque (cf ). Les composants applcatfs sont déployés sur les nœuds d'exécuton conçus lors de l'actvté d'archtecture technque statque (cf ). La valdaton d'éléments applcatfs réutlsables est une préconsaton fate pour un SI par un urbanste applcatf, expert de la vue applcatve du SI. 44

146 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 00 : Actvté d'archtecture applcatve statque L'expert transforme l'ensemble des parcelles fonctonnelles défnssant les îlots du système en un ensemble de composants applcatfs. Chaque composant applcatf représenté dans la Fgure 0 est alors déployé sur un nœud d'exécuton. La Règle d'urbansme Archtecture applcatve statque assure la cohérence entre les composants applcatfs, les parcelles fonctonnelles réalsées et les nœuds d'exécuton permettant le déploement de ces composants. Dans le cas partculer où le nœud d'exécuton est un élément réutlsable du SI, les composants applcatfs sont ceux défns dans la vue applcatve de cet élément. Règle d'urbansme Archtecture applcatve statque n 4 : - Chaque nstance de parcelle fonctonnelle ne peut être réalsée que par un seul composant applcatf ; - Chaque composant applcatf réalse, sot des parcelles fonctonnelles d'îlots de type flux, sot des parcelles fonctonnelles d'îlots de type stock ; - Chaque composant applcatf est déployé sur un seul nœud d'exécuton ; - Lorsque le nœud de déploement caractérse un élément du SI réutlsé, les composants applcatfs déployés sur ce nœud sont conformes à cet élément réutlsé, en partculer, à la défnton des composants applcatfs qu composent sa vue applcatve. Une llustraton du premer tem de la Règle d'urbansme Archtecture applcatve statque est que l'nstancaton de la parcelle fonctonnelle Recevor un message nstancée pour un message électronque ne peut être réalsée que par un seul composant applcatf. L'ntérêt du second tem est de séparer la réalsaton d'îlots de type flux de la réalsaton d'îlots de type stock. Cette séparaton permet de caractérser les échanges entre composants applcatfs. En effet, les requêtes envoyées vers un composant applcatf réalsant du flux sont corrélées à chaque usage du servce alors que les requêtes envoyées vers un composant applcatf réalsant du stock sont décorrélées de l'usage du servce. Le len de communcaton de la vue technque supportant ces échanges est ans rendu spécfque au typage de ce que réalse chaque composant cble d'une nteracton de type requête. 45

147 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PSM statque PDM PIM statque Expertse PSM statque Fgure 0 : Concepts et transformaton lés à l'actvté d'archtecture applcatve statque Un mode de représentaton des composants applcatfs est un dagramme de composants UML où chaque composant est stéréotypé <<composant applcatf>>. Le chox de l'archtecte applcatf du système est la concepton de tros composants représentés dans la Fgure 02 et appartenant à la vue applcatve des enablers réutlsés pour ce développement : - Messagere, - Stockage, - Sécurté. Fgure 02 : Illustraton de composants applcatfs de l'actvté d'archtecture applcatve statque 46

148 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le Tableau 4 représente les parcelles des îlots fonctonnels réalsées par chaque composant applcatf. Composant applcatf Parcelle fonctonnelle réalsée Îlot fonctonnel Messagere Recevor un message Récepton d'un message Fltrer un message par rapport à l'objet du message Sécurté de la messagere Fltrage de message Stockage Stocker un message Récepton d'un message Fltrage Consulter une règle de fltrage de message Sécurté de la messagere Gérer les règles de fltrage Tableau 4 : Illustraton du len de réalsaton d'une parcelle fonctonnelle par un composant applcatf de l'actvté d'archtecture applcatve statque. La Règle d'urbansme Archtecture applcatve statque (cf ) est vérfée pour le len de réalsaton avec les parcelles fonctonnelles pusque : - la seule nstance est celle d'un message électronque, - le composant applcatf Messagere ne réalse que des parcelles d'îlots fonctonnels de type flux, - le composant applcatf Stockage ne réalse qu'une parcelle d'îlot fonctonnel de type flux, - le composant applcatf Fltrage ne réalse qu'une parcelle d'îlot fonctonnel de type stock. Le dagramme de déploement UML de la Fgure 03 représente le déploement de chaque composant applcatf sur un nœud d'exécuton. Fgure 03 : Illustraton du len de déploement d'un composant applcatf de l'actvté d'archtecture applcatve statque sur un nœud d'exécuton 47

149 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI La Règle d'urbansme Archtecture applcatve statque est vérfée pour le len de déploement de chaque composant applcatf sur un nœud d'exécuton et pour la réutlsaton des enablers : - les composants applcatfs Messagere et Fltrage sont déployés sur le nœud d'exécuton Enabler Messagere, - le composant applcatf Stockage est déployé sur le nœud d'exécuton Enabler Stockage, - les composants applcatfs Messagere et Fltrage sont ceux défns dans la vue applcatve de l'enabler Messagere réutlsé, - le composant applcatf Stockage est celu défn dans la vue applcatve de l'enabler Stockage réutlsé Archtecture applcatve dynamque des composants L'actvté de concepton de l'archtecture applcatve dynamque des composants d'un système, entourée dans la Fgure 04, a pour objectf de concevor les nteractons entre composants applcatfs conçus lors de l'actvté d'archtecture applcatve statque (cf ). Les nteractons entre composants applcatfs réalsent les nteractons entre îlots fonctonnels décrtes lors de l'actvté d'archtecture fonctonnelle dynamque des îlots (cf ). Cette concepton des nteractons entre îlots fonctonnels est contrante par l'exstence de protocoles conçus lors de l'actvté d'archtecture technque dynamque (cf ). Comme pour l'actvté précédente, les éléments applcatfs réutlsables, en partculer les nterfaces applcatves, consttuent une préconsaton d'urbansme applcatf du SI. Cette préconsaton est à prendre en compte lors de l'actvté d'archtecture applcatve dynamque des composants. Fgure 04 : Actvté d'archtecture applcatve dynamque des composants 48

150 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI L'actvté d'archtecture applcatve dynamque des composants applcatfs est la transformaton du modèle des nteractons conçues entre les îlots de la vue fonctonnelle du système. Cette transformaton représentée dans la Fgure 05 est contrante par les composants applcatfs réalsant les îlots fonctonnels du système. L'exstence de protocoles entre les nœuds d'exécuton où sont déployés les composants applcatfs de l'nteracton est auss une contrante de la transformaton. L'automatsaton de la transformaton est rendue possble : - par le len entre les composants applcatfs de l'nteracton et les îlots fonctonnels qu'ls réalsent et - par le len entre les composants applcatfs de l'nteracton et les nœuds d'exécuton permettant leur déploement. La Règle d'urbansme Archtecture applcatve dynamque des composants permet cette automatsaton. Règle d'urbansme Archtecture applcatve dynamque des composants n 5 - Chaque nteracton entre îlots fonctonnels est réalsée par une seule nteracton entre composants applcatfs ; - S l'nteracton de type requête est adressée à une nstance du composant applcatf C 2 à partr d'une nstance du composant applcatf C, elle nécesste l'utlsaton par le composant applcatf C d'une nterface applcatve fourne par le composant applcatf C 2 ; - Chaque nteracton entre composants applcatfs est déployée sur le protocole qu rele les nœuds d'exécuton où sont déployés les composants applcatfs de l'nteracton ; - Lorsque l'un des deux nœuds de déploement relés par le protocole supportant l'nteracton caractérse un élément du SI réutlsé, les nteractons entre composants applcatfs déployés sur ce nœud dovent respecter la vue applcatve de cet élément réutlsé, en partculer la défnton des nterfaces applcatves. 49

151 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PSM dynamque PSM statque PDM PIM dynamque Automatsaton PSM dynamque Fgure 05 : Concepts et transformaton lés à l'actvté d'archtecture applcatve dynamque des composants D'après le second tem de la Règle d'urbansme Archtecture applcatve dynamque des composants (cf ) l est mmédat de dédure les nterfaces applcatves fournes et utlsées par chaque composant applcatf à partr des nteractons conçues entre composants applcatfs. Un mode de représentaton des nteractons entre composants applcatfs est un dagramme de séquence UML représentant les nstances de composants applcatfs réalsant un scénaro d'utlsaton du système. Chaque nteracton est lbellée par le nom de l'nterface applcatve utlsée lors de la requête. La représentaton de la successon temporelle d'nteractons et la représentaton de la dépendance d'nteractons respecte la Sémantque UML Approche dynamque et dagramme de séquence (cf. 2..5). Le mode de représentaton des nterfaces applcatves sont les nterfaces utlsées et fournes dans un dagramme de composants UML. 50

152 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Dans la Fgure 06, le dagramme de séquence composé d'nteractons entre nstances de composants applcatfs représente le scénaro SC-Fltrage négatf. Ce dagramme est le résultat de la transformaton du dagramme de séquence composé d'nteractons entre îlots fonctonnels de la Fgure 86. Le déploement des nteractons entre nstances de composants applcatfs sur le protocole FTP est schématsé par un cylndre sur le dagramme. Interactons déployées sur un protocole FTP Fgure 06 : Illustraton des nteractons entre composants applcatfs de l'actvté d'archtecture applcatve dynamque des composants Parm les dagrammes de séquence automatquement générés à partr du dagramme de séquence représentant des nstances d'îlots fonctonnels réalsant SC-Fltrage négatf, le dagramme de séquence retenu est celu de l'enchaînement d'nteractons ayant pour valeur ajoutée le stockage d'un message reçu après fltrage. 5

153 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le premer tem de la Règle d'urbansme Archtecture applcatve dynamque des composants (cf ) est respecté : - l'nteracton entre îlots fonctonnels Recevor un message est réalsée par l'nteracton entre composants organques Fltrer un message reçu ; - l'nteracton entre îlots fonctonnels Fltrer un message par rapport à l'objet du message est réalsée par l'nteracton entre composants organques Fltrer un message reçu ; - l'nteracton entre îlots fonctonnels Consulter les règles de fltrage de message est réalsée par l'nteracton entre composants organques Consulter les règles ; - les deux nteractons entre îlots fonctonnels Stocker un message sont réalsées par l'nteracton entre composants organques Stocker un message électronque. La satsfacton du derner tem de la Règle d'urbansme Archtecture applcatve dynamque des composants est soulgnée dans la Fgure 06 avec le déploement de l'nteracton Fltrer un message reçu sur le protocole FTP, sachant que : - le composant applcatf Stockage est déployé sur le nœud d'exécuton Enabler Stockage, - le composant applcatf Messagere est déployé sur le nœud d'exécuton Enabler Messagere, - le protocole FTP rele les nœuds d'exécuton Enabler Stockage et Enabler Messagere. Fgure 07 : Illustraton des nterfaces applcatves de l'actvté d'archtecture applcatve dynamque des composants Les nterfaces applcatves décrtes dans le dagramme de composants de la Fgure 07 respecte le deuxème tem de la Règle d'urbansme Archtecture applcatve dynamque des composants. Les nterfaces applcatves sont en effet cohérentes avec les nteractons décrtes dans le dagramme de séquence de la Fgure 06 : - L'nterface applcatve Stocker un message électronque fourne par le composant Stockage correspond à l'nteracton de requête, de même lbellé, adressée du scénaro à ce composant applcatf ; - L'nterface applcatve Fltrer un message reçu fourne par le composant Messagere et utlsée par le composant applcatf Stockage correspond à l'nteracton de requête, de même lbellé, entre ces deux composants applcatfs ; - L'nterface applcatve Consulter les règles fourne par le composant Fltrage et utlsée par le composant applcatf Messagere correspond à l'nteracton de requête, de même lbellé, entre ces deux composants applcatfs. 52

154 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Archtecture applcatve dynamque des données L'actvté de concepton de l'archtecture applcatve des données d'un système, entourée dans la Fgure 08, a pour objectf de concevor les attrbuts des données physques. Ceux-c sont les paramètres de sorte des nteractons entre nstances de composants applcatfs. Ces nteractons sont conçues lors de l'actvté d'archtecture dynamque des composants applcatfs (cf ). Les attrbuts des données physques réalsent des attrbuts de données logques conçus lors de l'actvté d'archtecture fonctonnelle dynamque des données (cf ). Le respect de la Règle d'urbansme Relaton de dépendance entre données (cf. 4..2) sgnfe que les nterfaces applcatves fournes et utlsées conçues lors de l'actvté d'archtecture dynamque des composants applcatfs peuvent évoluer lors de l'actvté d'archtecture applcatve dynamque des données. Fgure 08 : Actvté d'archtecture applcatve dynamque des données Le premer concept obtenu lors de l'actvté d'archtecture applcatve dynamque des données est l'attrbut d'une donnée physque décrt dans la Fgure 09. L'attrbut est en effet un paramètre d'entrée ou de sorte d'une, ou pluseurs, nteractons entre nstances de composants applcatfs. Le deuxème concept dédut mmédatement des attrbuts sont les données physques regroupant ces attrbuts. Le derner concept est celu des nterfaces applcatves fournes et utlsées par les composants applcatfs. La conformté des nterfaces applcatves aux relatons de dépendance entre données physques est stpulée dans la Règle d'urbansme Relaton de dépendance entre données (cf. 4..2). L'archtecture applcatve dynamque des données est la transformaton des attrbuts de données logques et des paramètres d'entrée ou de sorte des nteractons entre îlots fonctonnels en un modèle de données physques. La règle d'urbansme assocée à l'actvté d'archtecture applcatve dynamque des données assure la cohérence du modèle de données physques avec le modèle des composants applcatfs et de leurs nterfaces. 53

155 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI La défnton d'une relaton de dépendance entre données physques est dédute de celle des attrbuts de données physques. Défnton : Deux attrbuts, A et A 2, de données physques sont en relaton de dépendance telle que A dépende de A 2. - s A 2 est le paramètre d'entrée et A est le paramètre de sorte d'une nteracton de type requête entre nstances de composants applcatfs dans un dagramme de séquence UML, ou, - s A 2 est le paramètre de sorte d'une nteracton de type requête entre nstances de composants applcatfs succédant drectement à une nteracton de type requête entre nstances de composants applcatfs ayant pour paramètre de sorte A dans un dagramme de séquence UML. Défnton : Deux données physques sont en relaton de dépendance s au mons un attrbut d'une des données physques est en relaton de dépendance avec au mons un attrbut de l'autre donnée physque. La Règle d'urbansme Archtecture applcatve dynamque des données permet de vérfer la cohérence du modèle de données physques avec le modèle des composants applcatfs. Règle d'urbansme Archtecture applcatve dynamque des données n 6 - Tous les attrbuts d'une même donnée physque sont produts par un seul composant applcatf conformément à la Règle d'urbansme Donnée produte et composant applcatf (cf ) ; - Deux attrbuts, en relaton de dépendance, produts par le même composant applcatf peuvent être regroupés dans une même donnée physque ; - Chaque relaton de dépendance entre données physques est conforme à une nterface applcatve o fourne par le composant applcatf producteur de la donnée cble de la o dépendance et utlsée par le composant applcatf producteur de la donnée source de la dépendance ; - Lorsque le nœud de déploement du composant applcatf producteur d'une donnée physque caractérse un élément du SI réutlsé, la donnée physque produte par le composant applcatf déployé sur ce nœud dot respecter la vue applcatve de cet élément réutlsé, en partculer la défnton des données physques produtes. 54

156 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI PSM dynamque PIM dynamque Automatsaton PSM dynamque Fgure 09 : Concepts et transformaton lés à l'actvté d'archtecture applcatve dynamque des données Le mode de représentaton des données physques est le dagramme de classes UML stéréotypées <<donnée physque>>. Le dagramme de séquence UML représente les nteractons entre nstances de composants applcatfs. Les données physques et leurs attrbuts sont les paramètres d'entrée ou de sorte des nteractons. La donnée physque et son attrbut sont séparés par le caractère "/". Le mode de représentaton des nterfaces applcatves reste celu des nterfaces dans un dagramme de composants UML. Le dagramme de séquence des nteractons entre nstances de composants applcatfs représentant le scénaro SC-Fltrage négatf de la Fgure 06 est complété par les paramètres d'entrée et de sorte dans la Fgure 0. Les paramètres des nteractons de type requête sont les attrbuts des données physques résultant de la transformaton des paramètres d'entrée et de sorte des nteractons entre îlots fonctonnels représentés dans la Fgure

157 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 0 : Illustraton des données physques de l'actvté d'archtecture applcatve dynamque des données 56

158 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Le modèle de données physques résultant de la transformaton est consttué de : - la donnée physque Date de stockage défne par l'attrbut Date, - la donnée physque Talle de stockage de la messagere défne par l'attrbut Talle, - la donnée physque Récepton du message défne par l'attrbut Date, - la donnée physque Fltrage de message défne par l'attrbut Indcateur, - la donnée physque Règle de fltrage objet défne par l'attrbut Lbellé. L'llustraton de la Fgure 0 soulgne le respect de la Règle d'urbansme Archtecture applcatve dynamque des données. La producton d'une donnée physque par un composant applcatf est représentée par un len de dépendance stéréotypé <<produt>>. - l'attrbut Date de la donnée physque Date de stockage est produt par le composant applcatf Stockage, - l'attrbut Talle de la donnée physque Talle de stockage de la messagere est produt par le composant applcatf Stockage, - l'attrbut Date de la donnée physque Récepton du message est produt par le composant applcatf Messagere, - l'attrbut Indcateur de la donnée physque Fltrage de message est produt par le composant applcatf Messagere, - l'attrbut Lbellé de la donnée physque Règle de fltrage objet est produt par le composant applcatf Fltrage, - les relatons de dépendance o de la donnée physque Date de stockage vers la donnée physque Récepton du message, o de la donnée physque Date de stockage vers la donnée physque Fltrage du message, o de la donnée physque Talle de stockage de la messagere vers la donnée o physque Récepton du message, de la donnée physque Talle de stockage de la messagere vers la donnée physque Fltrage du message, sont conformes à l'utlsaton de l'nterface applcatve Fltrer un message reçu par le composant applcatf Stockage (relatons entourées et relées dans l'llustraton), - les relatons de dépendance o o de la donnée physque Récepton du message vers la donnée physque Règle de fltrage objet, de la donnée physque Fltrage du message vers la donnée physque Règle de fltrage objet, sont conformes à l'utlsaton de l'nterface applcatve Consulter les règles par le composant applcatf Messagere (relatons entourées et relées dans l'llustraton) Archtecture applcatve détallée L'actvté d'archtecture applcatve détallée, entourée dans la Fgure, permet de détaller : - les composants applcatfs conçus lors de l'actvté d'archtecture applcatve statque (cf ), - les nterfaces applcatves conçus lors de l'actvté d'archtecture applcatve dynamque (cf ) et - les données physques conçues lors de l'actvté d'archtecture applcatve dynamque des données (cf ). 57

159 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI La contrante est exprmée sous forme d'un modèle de couches applcatves, par exemple la couche de présentaton, la couche d'accès aux données, etc. Chaque composant applcatf et ses nterfaces sont projetés sur chacune des couches applcatves. Un envronnement archtectural, spécfque à chaque couche applcatve et conçu lors de l'actvté d'archtecture technque détallée (cf ), permet d'automatser l'actvté d'archtecture applcatve détallée. Cette automatsaton à partr d'un envronnement archtectural assocé à une couche applcatve est une applcaton classque de l'approche MDA. Fgure : Actvté d'archtecture applcatve détallée L'actvté d'archtecture applcatve détallée n'est pas explctée c car elle ne comporte pas de spécfcté dans la démarche EA4UP Implémentaton L'mplémentaton du système est une macro-actvté sous la responsablté de l'équpe de développement, sot la MOE du système. Cette macro-actvté, entourée dans la Fgure 2, nécesste que le système possède une archtecture applcatve détallée. L'objectf de l'mplémentaton est l'écrture du code dans chaque élément consttuant les dfférentes couches applcatves du système. 58

160 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 2 : Macro-actvté d'mplémentaton dans la démarche EA4UP L'actvté d'mplémentaton entourée dans la Fgure 3 permet de coder les éléments résultants de la projecton de chaque composant applcatf, de chaque nterface applcatve ou de chaque donnée physque sur une couche applcatve. Ces éléments ssus des dfférentes projectons sont conçus lors de l'actvté d'archtecture applcatve détallée (cf ). Un générateur de code spécfque à un consttuant d'une couche applcatve permet en général d'automatser l'actvté d'mplémentaton. La génératon de code ans automatsée est une applcaton classque de l'approche MDA. Fgure 3 : Actvté d'mplémentaton L'actvté d'mplémentaton n'est pas explctée c car elle ne comporte pas de spécfcté dans la démarche EA4UP. 59

161 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Test Le test du système est une macro-actvté sous la responsablté conjonte du clent du système, sot la MOA, et de l'équpe de développement, sot la MOE du système. La MOE dot tester le système qu'elle développe alors que la MOA dot effecteur la recette du système à partr des résultats des tests. Cette macro-actvté, entourée dans la Fgure 4, nécesste que le système sot mplémenté. La macro-actvté de test comprend pluseurs actvtés telles que le test fonctonnel et le test de robustesse et de performance. Fgure 4 : Macro-actvté de test dans la démarche EA4UP L'actvté de test fonctonnel, entourée dans la Fgure 5, permet, à partr de la reformulaton des exgences fonctonnelles réalsée lors de l'actvté d'analyse fonctonnelle dynamque (cf ), de tester les éléments codés lors de l'actvté d'mplémentaton (cf ). Ces éléments consttuent des composants applcatfs, des nterfaces applcatves ou des données physques. 60

162 La démarche EA4UP de développement de système asssté par l'urbansme fonctonnel d'un SI Fgure 5 : Actvté de test fonctonnel L'actvté de test de robustesse et de performance, entourée dans la Fgure 6, permet à partr de la reformulaton des exgences non fonctonnelles réalsée lors de l'actvté d'analyse technque dynamque (cf ), de tester les éléments codés lors de l'actvté d'mplémentaton (cf ). Ces éléments consttuent les composants applcatfs, les nterfaces applcatves ou les données physques. Fgure 6 : Actvté de test de robustesse et de performance 4.3 Évaluaton de la démarche EA4UP L'actvté de réalsaton du blan du développement d'un système, entourée dans la Fgure 7, recouvre, lors du prototypage de la démarche EA4UP, son évaluaton. La démarche a été prototypée par pluseurs projets de développement de servces télécom. 6