modélisation des phases amont - la convergence uml… · réussir la modélisation uml des phases...

Réussir la modélisation UML des phases

amont Techniques de « pré-modélisation » : un pont vers le modèle

© Softeam 2004 Philippe Desfray (voir A propos de l’auteur)

Présentation Réussir le développement d’une application logicielle demeure toujours une gageure en ce début de 21e siècle. Selon le Standish Group1, si vous décidez de développer une application logicielle, vous encourez un risque d’échec de 23%, un risque de dérapage (en dehors des prévisions fonctionnelles ou de délai/budget initiales) de 49%, et une chance de succès de 28%. Et encore ces chiffres confondent-ils les évolutions d’applications existantes et le développement de nouvelles applications, ce dernier cas étant évidemment bien plus exposé au risque d’échec. Le succès ou l’échec d’un développement se jouent essentiellement lors des phases amont du développement logiciel. C’est là où les acteurs principaux qui déterminent les choix fondamentaux – les décisionnaires, les utilisateurs, les maîtres d’ouvrage – bâtissent l’objectif stratégique ; c’est là où le contour du domaine à traiter, et où les engagements fonctionnels, budgétaires, de planning, et architecturaux apparaissent. A ce stade, l’enjeu est de définir des objectifs compris par tous2, réalistes, recouvrant exhaustivement la vision initiatrice du projet. Face à une analyse préliminaire réussie, à une liste d’exigences bien formalisée et à une définition du domaine suffisamment complète, la réalisation du développement permet d’isoler et de réduire les risque qui pourront être maîtrisés par :

• une bonne sélection des ressources de développement; • une compétence technique assurée; • un budget et un planning réalistes; • une conduite de projet bien organisée et bien suivie; • une méthode de développement et une assurance qualité adaptées à la topologie du

projet. Sur quelles bases, quelles techniques et quelles méthodologies doit-on s’appuyer pour réaliser les phases amont ? Nous allons voir que la réponse dépend largement du contexte, mais qu’une panoplie de techniques existe, et fournit des aides utiles pour réussir la réalisation des phases amont de développement.

1 Chaos Report, Standish group, 2001 2 Dans certains cas, comme par exemple sur des domaines innovants en termes de produits et services, l’objectif n’est initialement pas totalement élucidé. Il s’avère alors nécessaire de définir les objectifs identifiés, et de procéder itérativement dans les étapes ultérieures jusqu’à obtention d’un cahier des charges complété.

Réussir la modélisation des phases amont page2

Objectif des phases préliminaires du développement Il est nécessaire de définir les domaines d’application sur lequel un système doit être mis en place et les processus que le système doit équiper. La terminologie, les définitions et le contour du domaine sont clarifiés, afin de poser le problème dans un contexte clair. Dans ce domaine, les modes de fonctionnement doivent être explicités, sous forme de procédures métier, mais aussi sous forme de règles et contraintes métiers. L’existant doit être analysé, en étant représenté comme un système dont on montre la structure, les rôles, les responsabilités et échanges d’informations internes ou externes. On cherche à collecter toute l’information préliminaire, que celle-ci soit sous forme de documents, de modèles, de formulaires ou de toute autre représentation. On explicite la nature des produits élaborés par les processus. Face à cette analyse, il faut ensuite identifier les points faibles, les points à améliorer ou les nouveaux points à introduire constituant la base de la définition du futur système. Le terme « système » est à prendre ici dans son sens le plus large : dans le monde des systèmes d’information, le système est l’ensemble de l’organisation permettant de fournir un service, d’effectuer des traitements et opérations. Il s’agit d’une organisation humaine, matérielle, dont seule une partie est assumée par le logiciel. Dans le monde des systèmes techniques, il s’agit d’un assemblage « matériel physique / hardware / logiciel », ces éléments pouvant être conçus conjointement. La définition des fonctions à assumer par le logiciel, qui peut être développé spécifiquement ou repris sur étagère, ainsi que l’articulation des responsabilités entre le logiciel et les autres acteurs appartient aux phases préliminaires. A ce stade, les représentations de l’existant sont reprises, pour présenter le système conformément à la vision et aux objectifs d’évolution. Dans le cas plus rare d’applications nouvelles, il n’y a pas toujours de besoins de représentation de l’existant, mais la définition des domaines et processus nécessite un travail plus soutenu. Dans ces phases préliminaires, un enjeu majeur consiste à utiliser des représentations permettant un dialogue entre les parties impliquées comme les utilisateurs, les analystes, les responsables hiérarchiques et les experts du domaine. L’emploi exagéré de techniques de modélisation comme UML constitue un obstacle à la compréhension pour certains intervenants, et ira à l’encontre de leur implication dans la modélisation ou les revues. A contrario, l’absence d’une méthode rigoureuse de représentation empêchera la collecte d’une information précise, cohérente et exhaustive, que l’on peut abstraire ou détailler selon les niveaux de dialogue. On en viendra donc à combiner plusieurs techniques, pour adresser spécifiquement chaque type de problème, mais aussi pour fournir des représentations compréhensibles par les diverses catégories de personnes impliquées dans les phases amont. Les phases préliminaires fourniront des représentations qui constitueront la base d’un contrat3 pour les développeurs de l’application. Cette dimension contractuelle renforce encore la nécessité que tous puissent comprendre et partager ce qu’il exprime. Elle introduit un mode de gestion très particulier des livrables issus de cette phase :

3 Il ne s’agit qu’un des nombreux éléments du contrat, qui devra préciser par exemple le partage des rôles et responsabilités ainsi que les modalités d’organisation lors de la phase de réalisation.

© SOFTEAM 2004


on ne modifie pas un contrat impunément. Chaque modification nécessite un accord partagé, tant sur sa nature que sur ses conséquences. L’historique des changements contractuels doit être préservé ; on doit se référer constamment au contrat pour justifier le travail réalisé par la suite. Il

faut ainsi garantir que chacun des termes du contrat a été satisfait par l’application développée, et que les constituants de l’application sont tous justifiés par un lien avec le contrat initial. A ce stade, la « traçabilité » devient un facteur clé pour maîtriser le développement.

© SOFTEAM 2004


Techniques employées lors des phases préliminaires

Vue générale Il est dangereux de produire prématurément des modèles. La modélisation impose une vision « formelle » du problème, détermine des choix qui peuvent s’avérer prématurés, et produit facilement un assemblage de boîtes et de liens non représentatifs de la réalité du problème et des objectifs. Il est avant tout fondamental de répertorier une information fiable sur la nature du problème à traiter et sur les objectifs. En revanche, il est très intéressant de réaliser des modèles, car ils formalisent le problème, figent le cadre du développement, et permettent d’identifier des manques de l’analyse préalable en contraignant l’analyste à décrire l’implicite, et à produire une certaine exhaustivité. Ils permettent de rendre cohérente une base initiale trop informelle. Outre la formalisation nécessaire à la réalisation du logiciel, le modèle apporte aussi au métier la maîtrise de ses propres concepts et l’explicitation de ses procédures. La Figure 1 montre qu’il est ainsi nécessaire d’associer plusieurs techniques informelles ou formelles de modélisation, pour pouvoir saisir toutes les facettes d’un problème sans le dénaturer, et ensuite les détailler dans un modèle central, qui peut être raffiné et retravaillé jusqu’à l’implémentation.

Modèle formel et détaillé

VérificationElaboration

Use Case

Dictionnaire

Représentation systèmeVue générale

Exigences

Processus métier, règles métier

Figure 1 - Association de modèles formels et informels en phases préliminaires

A titre d’exemple, la construction d’un modèle peut débuter par le recueil des exigences et du dictionnaire d’une application, pour se poursuivre par un modèle des procédures métier et un modèle des notions du domaine, qui seront tracées par rapport au dictionnaire et exigences initiales. Ensuite, un modèle de cas d’utilisation permettra d’isoler l’exploitation du système d’information au sein du système global, tracé et déduit des procédures métiers et des exigences. Enfin, le modèle applicatif sera lui même tracé sur ces modèles initiaux.

© SOFTEAM 2004


La Figure 2 illustre un cycle de développement pouvant être pratiqué pour itérer des modèles les plus informels au modèle complet et formel. Des intervenants non informaticiens peuvent intervenir sur les représentations informelles.

Expert du domaineUtilisateur

Analyste

Modèle préliminaire(informel et général)

1 obtention des informations Préliminaires : le métier, les exigences, …

2 Revue du modèle préliminaire

Modèle UML (Formel etdétaillé)

3 Formalisation,Justification

Analyste

Expert du domaineUtilisateur

Analyste

Modèle préliminaire(informel et général)

1 obtention des informations Préliminaires : le métier, les exigences, …

2 Revue du modèle préliminaire

Modèle UML (Formel etdétaillé)

3 Formalisation,Justification

Analyste

Figure 2 - Etapes de construction des modèles en analyse préliminaire

Sans prétendre à l’exhaustivité, les techniques les plus fréquemment utilisées sont présentées ci-dessous. En pratique, elles sont employées selon un grand nombre de variantes, y compris dans leur dénomination. On assiste cependant, et pour chacune d’entre elles, à des mouvements d’uniformisation et de consolidation, se traduisant soit par des outillages ayant des fonctionnalités similaires, soit par des livres dédiés à ces pratiques, ou même des efforts de standardisation comme ceux de l’OMG4 sur l’approche « system engineering », « business rules », ou encore « Business Process Modeling ».

Dictionnaire : termes et définitions pertinentes relatifs au système. Le dictionnaire est un moyen très simple et efficace pour décrire le domaine de l’application. Approche systémique : représentation globale du système présent et futur. Fournit les

responsabilités du système. Derrière les préoccupations de cette approche, on retrouvera les techniques de l’analyse systémique déjà connues dans l’approche Merise, les approches de « system engineering » pratiquées dans le domaine technique, et les techniques de cartographie des applications utilisées dans le domaine des systèmes d’information. Analyse des besoins et des exigences : classifiés, formalisés, maintenus, tracés, on

trouve des pratiques très similaires fournies par plusieurs ateliers et préconisés par plusieurs démarches. Modélisation des processus métier : Cette technique est essentielle pour la définition

des procédures d'une organisation. Certains outils apportent une notation spécifique à cette technique, mais UML fournit un formalisme adapté appelé « Activity Diagram ». Règles métier : description des règles fondamentales régissant le fonctionnement d'une

organisation. Plusieurs familles d’outils supportent cette approche sous des formes très

© SOFTEAM 2004

4 OMG : Object Management Group, organisme de standardisation ayant notamment standardisé CORBA, et UML


différentes. Le langage UML fournit une base pour les exprimer grâce aux notions de contrainte, d’invariant, de pré ou post conditions. Cas d’utilisation : description des grands cas d'utilisation internes au système. Très

utilisée par les praticiens de UML, cette technique est sous-tendue par des démarches de modélisation communément utilisées. Modèles conceptuels : UML permet de représenter les notions saillantes d’un domaine

ou d’un système, et ainsi de formaliser les connaissances préliminaires du système, notamment par l’exploitation des diagrammes de classes.

L’ensemble des informations recueillie par le biais de ces techniques permet de constituer le référentiel du système. Le référentiel permet d’identifier les éléments présents dans le système d’information, ainsi que de fournir des nomenclatures qui seront constamment exploitées et référées sur l’ensemble du cycle de vie des développements et évolutions du système. Un effort particulier doit être entrepris pour obtenir de la part de l’ensemble des parties prenantes relatives au système et à ses évolutions, la validation et l’appropriation des modèles et informations recueillis. Des outils spécifiques sont nécessaires pour présenter le modèle aux divers niveaux des responsables hiérarchiques des métiers de l’entreprise, ainsi que pour le présenter aux utilisateurs finals et leur permettre de comprendre l’organisation du processus ainsi que le rôle que chacun des utilisateurs doit remplir La gestion de la traçabilité est un élément important dans l’ensemble de l’approche. La mise en œuvre simultanée de techniques différentes impose en effet de gérer la cohérence globale, de garantir la complétude de chacune des facettes, et de permettre des vérifications croisées. De manière générale, le standard de modélisation UML apporte une assistance importante lors de la modélisation des phases amont. Cette assistance sera encore renforcée par les extensions du standard UML2.0, récemment adopté (Juin 2003). Cependant, UML ne couvre pas tous les besoins pour ces phases, où des extensions et des techniques complémentaires sont nécessaires. Le Tableau ci dessous montre de manière synthétique le degré de support que UML fournit pour les techniques de modélisation des phases amont.

© SOFTEAM 2004


Technique Support UML Support Outillé Analyse des besoins Néant Outils dédiés indépendants ;

Objecteering/UML supporte les exigences comme une extension UML

Dictionnaire Néant Support du dictionnaire comme une extension UML

Modélisation des processus métier (BPM)

Activity Diagrams L’OMG fournira des extensions standards pour ce besoin

Outils indépendants, ou outils UML (diagrammes d’activité avec des extensions dédiées (profils)5)

Règles métier Contraintes, Invariants, Pre/Post conditions

Outils dédiés, ou outils UML avec des extension (profils) spécifiques

Approche systémique Diagrammes de paquetages, « subsystem », Information flow (UML2.0), modèles d’assemblages (UML2.0) L’OMG fournira un standard dédié au « system engineering »

Outillages spécifiques pour la cartographie des SI, Outillages dédiés pour l’ingénierie des systèmes, Outillages UML. Ils peuvent être spécifiquement étendus (profils) pour la cartographie, ou pour le support du « system engineering ».

Cas d’utilisation Cas d’utilisation Outils UML. Objecteering/UML offre des extensions méthodologiques pour l’emploi des cas d’utilisation en phases amont.

Modèles conceptuels Diagrammes de classe Outils UML Traçabilité Notion de « dependency » Techniques spécifiques à chaque outil.

Quelques ateliers UML (dont Objecteering/UML) supportent la traceabilité traçabilité.

Dictionnaire La technique du dictionnaire est la plus simple et la plus immédiate à appliquer. Bâtir un dictionnaire, c’est tout simplement répertorier les termes propres à un domaine d’application, et en produire la définition. C’est un travail fondamental, toujours utile, pouvant être entrepris dès le début. La terminologie d’un domaine est une connaissance essentielle, préliminaire à toute décision fonctionnelle et tout choix d’implémentation, qui bénéficie d’une très grande stabilité une fois finalisée. Il n'appartient pas aux développeurs mais bien plus aux spécialistes du domaine de définir la terminologie d’un domaine. Une fois établi, le dictionnaire est un guide précieux pour les développeurs, qui pourront en extraire un nommage cohérent du modèle. Il constitue un outil de mesure de complétude et de pertinence des modèles, en exploitant la traçabilité entre un dictionnaire et un modèle. Le dictionnaire peut être tolérant dans son recueil de terminologie : il accueille la diversité des vocabulaires qui coexistent dans l’organisation ou le domaine. Le modèle devra opérer une réduction terminologique en choisissant de ne nommer qu’une seule fois une même chose ou un même concept.

5 Le « profil UML » est un mécanisme standard UML pour étendre UML pour un objectif spécifique (domaine d’application, technologie ciblée, méthodologie)

© SOFTEAM 2004


Approche systémique Pour les systèmes de grande ampleur, où bien souvent un existant est à prendre en compte, il est nécessaire de construire des schémas généraux qui transcrivent une vision globale des constituants d’un système, et de leur mode de coopération. Sur ces schémas, il est important de construire un dialogue et d’avoir l’approbation de tous. Le modèle d’organisation représente les structures de l’entreprise impliquées dans les processus métier avec les échanges d’information. Il met en valeur les responsabilités des sous-systèmes représentés.

Commande

BonLivraison

Produit

ProduitBonLivraison

Commande

BonProduction

FinProduction

Facture

COMMERCIAL

COMPTABILITÉ

PRODUCTION

LIVRAISON

RèglementClient

Flux de données

Package

Figure 3 - Diagrammes de flux(Objecteering/UML) illustrant les échanges d’informations entre sous-systèmes

UML2.0 introduit la notion de « flot d’information », apportant de nouvelles capacités pour présenter la coopération des sous-systèmes. SOFTEAM, qui a introduit cette notion dans le standard UML2.0, l’implémente depuis plusieurs années dans l’atelier Objecteering/UML. La cartographie urbanisée des systèmes d’information, est une variante de l’approche systémique, permettant de superviser le patrimoine applicatif d’une entreprise en introduisant notamment les dimensions EAI (Enterprise Application Integration) et workflow. Elle fait office de préalable à toute évolution du système d’information et de ses applicatifs, en produisant le schéma d’ensemble de l’existant, et explicitant les évolutions urbanistiques prévues dans un système. Les démarches de modélisation de l’urbanisation d’un système varient selon les sociétés et les praticiens. UML est utilisé de manière de plus en plus générale, à travers sa panoplie de modèles : diagrammes de classes pour les objets métiers, diagrammes d’interaction pour exprimer les échanges et cas de coopération, diagrammes d’activité pour les processus métier, diagrammes de paquetages pour montrer une vision générale du système. UML 2.0 n’étant pas encore pratiqué, les nouveaux outils comme les flots d’information évoqués ci-dessus, mais aussi les modèles d’assemblage (notions de « part », de « port », de « connecteur », de « composant » …), fort utiles pour exprimer la constitution d’un système, ne sont encore que rarement mis en œuvre. L’ingénierie des systèmes est une matière pratiquée pour les systèmes techniques tels que les systèmes de contrôle de trafic aérien, les systèmes d’armes. Dans ces systèmes, qui sont eux-mêmes constitués d’autres systèmes, les composantes vont du matériel physique (avion, char, etc.) aux éléments « hardware », et aux éléments logiciels en passant par les éléments humains; ils mettent en œuvre une grande variété de technologies. Un effort de

© SOFTEAM 2004


standardisation est en cours au sein de l’OMG, afin de définir une manière homogène d’employer UML2.0 (un profil UML) entre les acteurs de ce domaine. L’ingénierie des systèmes est également centrée sur la composition d’un système en sous-systèmes, et sur la coopération et les modes d’intervention des sous-systèmes. Elle attache une importance particulière aux contraintes non fonctionnelles, comme typiquement les performances, les débits, les temps de réponse, les consommations mémoires, etc. Les modèles d’assemblage de UML2.0 constituent un élément très attendu par les praticiens de ce domaine. L’ingénierie des systèmes exploite également fortement les techniques d’analyse des besoins, et fait appel à la simulation logicielle pour garantir que la configuration des systèmes assemblés sera effectivement cohérente, en apportant la couverture fonctionnelle souhaitée conjointement à des performances acceptables prévues conformément au cahier des charges.

Règles métier Les règles métier sont constituées d’un ensemble de règles déterminant le fonctionnement du métier. Ce peut être des règles qui empêchent, provoquent ou permettent le déclenchement de processus, comme par exemple une assertion qui définit ou contraint certains aspects du métier, un terme ou un fait (assertion structurelle) qui fournit des informations sur le métier ou une contrainte régissant les actions et processus au sein du système. Une règle doit être « atomique », c’est à dire qu’elle ne peut pas être re-découpée en « sous règles ». On peut par exemple considérer le code civil comme un ensemble de règles métier régissant la société. Les règles métier apportent un modèle abstrait, relativement stable6 et indépendant des choix techniques sous jacents. Elles constituent une vision complémentaire des autres techniques employées en phase préliminaire. UML fournit la notion de « contrainte », permettant d’associer des contraintes à toutes parties d’un modèle. En adaptant cette notion aux différents types de règles métier (profil UML dédié), UML peut ainsi supporter la représentation des règles, avec l’avantage de les situer dans le contexte des éléments sur lesquels elles s’appliquent. Exemples : •Un commercial ne peut pas gérer plus de deux domaines, et/ou 10 clients. •Un client ne peut commander par le web, que s'il a été préalablement enregistré. •Les clients réputés moins solvables ne peuvent pas commander les produits haut de gamme, et ne peuvent commander plus que le seuil d'entrée sans garanties supplémentaires. •Un employé marié ne doit être muté qu'en dernière priorité.

Modélisation des processus métier Cette technique est très fréquemment utilisée dans le cadre de développement de systèmes d’information. Un processus métier est constitué par un ensemble d’activités réalisées par des acteurs afin d’atteindre un but précis. Par exemple, « Souscrire un nouveau compte » pour un système bancaire ou « Traiter un sinistre » pour un système d’assurance sont des processus métier. Un processus métier décrit le métier, et non le système informatique. Les activités d’un processus métier peuvent cependant être liées au système d’information. Certaines activités d’une procédure peuvent également être indépendantes du système informatique. On 6 La stabilité des règles métier peut être remise en cause lors de changement importants tels que des changements de réglementation.

© SOFTEAM 2004


cherche à formaliser les flux et la synchronisation des différentes tâches impliquées dans la

Figure 4 – Diagramme d’act

réalisation d’un service.

ivité UML représentant un processus métier (traitement dune commande, modèle

Le niveau présenté Figure 4 est déjà très détaillé, et suppose un bon niveau de consensus.

és,

Analyse des besoins ctifs d'un système à réaliser. Formalisé sous forme d’un

de un

rmet par s

t par exemple aider à identifier ou à justifier la présence des

relatifs aux performances du système, à leur disponibilité, aux taux d’erreur toléré, etc.

Clie n t: Ve n d e u r: Co mp ta : Liv ra is o n :

Co ma n d e u n p ro d u it

T ra ite me n t c o mma n d e

Fa c tu ra tio n

[Tra nsmise ]Comma nde :

[P ris e n c ompte ]Comma nde :

Liv ra is o n

[Emise ]Fa c ture :

R e c e p tio n

P roduit:

Liv ra is o n e ffe c tu é e

S o ld eP a ie me n t[R é glé e ]Fa c ture :

partiel)

Avant d’arriver à ce stade, il est nécessaire d’obtenir un accord sur la liste des processus relevant du domaine à modéliser. Il faut s’appuyer sur les points fondamentaux, comme typiquement les processus externes, dans lesquels le client ou les partenaires sont impliquavant de présenter les processus « internes » parfois plus conflictuels.

Un besoin exprime un des objeidentifiant (nom, numéro…) et de quelques phrases courtes exprimant le besoin, il possèensemble de propriétés (priorité, origine, etc.) qui permettent de le gérer. Les besoins ont très souvent une nature contractuelle : leurs identification, gestion, traçabilité est fondamentale pour gérer leurs évolution, et pour mesurer la couverture et le respect d’un modèle relativement aux besoins. La traçabilité exprimée entre des besoins et un modèle peailleurs d’établir des mesures d’impact, pour par exemple connaître les modifications induitepar l’évolution d’un besoin. L’expression des besoins peuprocessus. On identifiera des besoins externes, comme par exemple les besoins des clientsrelatifs aux services d’une organisation, des besoins internes comme par exemple respecter des contraintes de qualité, légales, de traçabilité, et des besoins dit « non fonctionnels »

© SOFTEAM 2004


L’analyse des besoins peut être conduite suivant des méthodologies spécifiques, qui procureront des classifications en types de besoins (exemple : fonctionnels, non fonctionnels,

besoins exprime les

La technique des Cas d’utilisation (Use Case) est très populaire chez les praticiens UML. Son cadre d’utilisation s’a entifié. Son

d’un

on, dologique bien documenté. L’avantage de la modélisation des cas

e en

èle des cas d’utilisation s’applique dans un contexte bien défini : le périmètre nctionnel du système est identifié, et les exigences globales, les objectifs généraux du

une ion

ergonomiques, etc.), et attacheront de nouvelles propriétés à un besoin. S’appuyant sur une définition du domaine et du métier apportée par le dictionnaire, sur les règles métier, et sur la modélisation des processus métiers, l’analyse desmotivation conduisant au développement ou à l’évolution d’un système.

Cas d’utilisation

Figure 5– Exemple de diagramme de cas d’utilisation UML

Utilisateurde la messagerie

courrier

1) l’utilisateur saisit son nom et son mot de passe2) le système vérifie la validité de l ’identification [E1]3) l’utilisateur demande la mise à jour des messages4) Le système rapatrie les messages depuis le bureau de poste [E2]5) Le système indique le nombre de nouveaux messages [E3]6) l ’utilisateur accède à l’ensemble des messages non lus7) l’utilisateur sélectionne un message et l’ouvre8) le système affiche le contenu du message

consultation en cours sur le poste de travail.

Erreurs:- [E1] Identification erronée : opération annulée - [E2] Connexion impossible : opération annuléeExceptions- [E3] il n’y a pas de nouveau message: information de l’utilisateur. Les séquences suivantes ne sont pas réalisées

Pré condition:Il n’y a pas une autre Consulter le

pplique au système à développer une fois celui-ci idutilisation intervient donc après celle de la modélisation des processus métier, de la définition du dictionnaire, et de la description des règles métier. Par exemple, pour toute activité processus métier qui utilise le système, on doit trouver un ou plusieurs cas d’utilisation permettant de la réaliser. De nombreux ouvrages ont été publiés sur la mise en œuvre du modèle des cas d’utilisatiassurant un support méthod’utilisation est de permettre une définition externe du système, en identifiant les acteurs pouvant intervenir, et les grands cas de figure de mise en oeuvre du système futur. Un modèlde cas d’utilisation est structurant pour l’activité d’analyse, et pour la modélisation future UML. Le modfosystème sont connus. Son emploi doit se limiter à la découverte « gros grain » des cas d’utilisation, chaque fois associés à au moins un acteur externe, et réalisant à chaque foisfonction complète (« transaction fonctionnelle »). Parfois, des modèles de cas d’utilisat

© SOFTEAM 2004


dérapent en de véritables décompositions fonctionnelles des services du systèmes, ce qui in fine nuira à une bonne modélisation et conception du système.

Ordonnancement des ces techniques de modélisation ne méthodologie ela dépend du

re.

st de partir des aspects les mieux connus, les plus généraux, les plus immédiats et s plus stables, pour ensuite détailler progressivement, en recherchant constamment le

s ent très en

délisation des processus métiers. En effet, les processus exploitent les données. Ils

e que

L’ordonnancement précis de ces techniques de modélisation s’appuiera sur uqui dépendra fortement du contexte dans lequel elles sont mises en œuvre. Cdomaine d’application, de la taille et de l’importance du problème à traiter, et de nombreux autres facteurs. Fréquemment, seule une partie des techniques mentionnées est mise en œuvPlusieurs types de représentation peuvent être construit en parallèle, par une démarche itérative. La règle eleconsensus et l’appropriation des représentations par les autres intervenants. Le dictionnaire peut toujours être défini en premier. Il permet de recueillir les définitionexistantes sans apporter d’interprétation. Les exigences interviennent égalemamont. L’approche systémique offre le moyen de fournir rapidement une vision globale dusystème. La définition des modèles conceptuels peut ensuite précéder ou être menée conjointement avec la mose justifient par les produits réalisés, et permettent d’identifier la nécessité de certaines données intermédiaires. Les règles métier viennent enrichir les modèles conceptuels, et les modèles des processus. Les cas d’utilisation interviennent en dernier lieu, en détaillant cle système d’information doit effectuer au sein d’un système global.

© SOFTEAM 2004


Apport d’un outillage supportant la modélisation des phases amont

Figure 6– Atelier Objecteering/UML – support des phases amont (module « UML requirements »)

L’ensemble des techniques pouvant être employées dans les phases amont, que celles ci relèvent de la description textuelle, ou de la modélisation, doit être coordonné à la fois par un processus de développement approprié, et par un outillage fédérateur. Un référentiel commun géré par l’outil est nécessaire. L’outil assure par ailleurs la coopération étroite entre les différentes formes de représentation, en maintenant la cohérence d’ensemble. Par exemple, la traçabilité doit être supportée et si possible automatisée par des assistants, afin de gérer les degrés de couverture de la modélisation, les correspondances entre différents niveaux de modélisation et les études d’impact des changements. Un outillage approprié permet d’offrir des vues différentes d’un même modèle, apportant pour chaque type de technique une ergonomie dédiée comme par exemple des éditeurs graphiques UML, des tableurs pour saisir le dictionnaire ou les exigences. Les facultés d’extension et d’adaptation de UML (profils UML) permettent à l’utilisateur d’adapter UML à ses besoins et sa démarche, souvent conditionnée par l’entreprise et le secteur d’application. Enfin, l’outillage doit apporter une productivité accrue des développeurs, ce qui outre le gain d’efficacité assure une bonne acceptation par les développeurs de l’outillage et de la démarche sous jacente. Les fonctions essentielles sont des fonctions de production de documentation automatique, permettant à partir des travaux sur des modèles ou des éléments textuels structurés de produire des documents suivant un format propre à l’entreprise. L’outil assure une transition et une reprise d’information entre phases, apportant par là un fort gain de productivité et de qualité. La production d’une documentation unifiée et cohérente à partir des modèles et des ajouts de commentaires en langage naturel permet également de relire et d’effectuer des revues globales, commentaires inclus, afin d’apporter une validation humaine toujours indispensable.

© SOFTEAM 2004


Figure 7– Atelier Objecteering/UML – définition conjointe des « cas d’utilisation » et des exigences

Des informations complémentaires peuvent être trouvées sur www.objecteering.com.

© SOFTEAM 2004

http://www.objecteering.com/


A propos de l’auteur Philippe DESFRAY, co-fondateur et directeur technique de SOFTEAM, est un expert internationalement reconnu des modèles et méthodes, en particulier centrés sur UML. Créateur de la méthode objet “Classe Relation” dans les années 1990, il a publié trois livres, en particulier “Object Engineering - The fourth dimension - ADDISON WESLEY - 1994.”, et a piloté le développement de l’atelier UML « Objecteering ». Précurseur des technologies « MDA7 », il a introduit dès 1994 des outils supports de cette approche. Depuis 1994, Philippe Desfray représente de SOFTEAM au sein de l’OMG où il participe à l’élaboration de plusieurs standards, dont notamment UML. Ses travaux continus sur le développement guidé par le modèle l’ont conduit à participer, dès l’origine, à la définition du standard UML, en y dirigeant la définition de nouvelles notions comme par exemple les « profil UML », et à faire développer son support outillé au sein de l’atelier Objecteering. Dirigeant une forte activité R&D au sein de SOFTEAM et en coopération avec de grands organismes européens, Philippe Desfray œuvre pour une application directe des résultats au sein des diverses activités de SOFTEAM : conseil, formation et support outillé par l’atelier Objecteering.

Remerciements Ce white paper a bénéficié des retours et consolidation des personnes suivantes, expertes dans les problématiques de modélisation, méthodologie et de définition de cahiers des charges. Je les remercie chaleureusement de leur efforts.

Arnaud Ladrière Laurent Lieber

Dominique Vauquier Michel Volle (http://www.volle.com)

7 « Model Driven Architecture » : démarche et technologie sous tendant les nouveaux standards de l’OMG

© SOFTEAM 2004

http://www.volle.com/

modélisation des phases amont - la convergence uml… · réussir la modélisation uml des phases...

Documents