Introduction

UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus d’élaboration des modèles. Cependant, dans le cadre de la modélisation d’une application informatique, les auteurs d’UML préconisent d’utiliser une démarche :
• itérative et incrémentale,
• guidée par les besoins des utilisateurs du système,
• centrée sur l’architecture logicielle.
D’après les auteurs d’UML, un processus de développement qui possède ces qualités devrait favoriser la réussite d’un projet. Mais que recouvre la notion de projet ?

La notion de projet
La notion de projet est souvent considérée différemment selon le secteur d’activité dans lequel on se trouve. Ainsi, un « projet » dans le domaine commercial sera-t-il abordé différemment d’un projet dans un développement de microélectronique, et encore différemment dans un projet informatique. Or, il s’agit fondamentalement d’une seule et même chose! Dans ce cas, on devrait pouvoir utiliser des méthodes identiques pour ces diverses modélisations.
C’est effectivement le cas pour les modélisations orientées objets, mais pas pour les modélisations basées sur la notion de procédure : la procédure est une notion trop abstraite pour être aisément traduite en termes matériels. Un PLL (Phase Locked Loop, boucle asservie en phase) est un objet faisant partie, avec d’autres, d’un objet plus complexe qui est un démodulateur FM. En revanche, comment mettre en relation le circuit intégré implémentant la fonction de démodulation avec les fonctions de Bessel décrivant le spectre de la modula tion, de manière à ce que cette relation soit utilisable tout au long de la chaîne de développement ? Clairement, il apparaît que les mathématiques (donc, les algorithmes) ne sont nécessaires qu’à un niveau atomique du fonctionnement de notre système, alors que le fonctionnement global doit être décrit d’une autre manière.

Comment minimiser les risques ?
Il est évident, dans ce modèle, que plus la détection d’une erreur de conception se fait tardivement, plus le coût nécessaire à la correction sera élevé. Le scénario catastrophe pourrait être le suivant :
• Le test système, chez le client, fait apparaître une faute grossière relativement à la spécification, faute liée à l’environnement du client, ce qui explique que le test d’intégration n’ aie pas su la déceler. La société est contrainte de reprendre le produit.
• Sur la base des indications fournies par le client (si tant est qu’indications il y a !), l’équipe de test parvient à reproduire et à documenter, dans un rapport de test, la faute à l’intention de l’équipe de développement.
• L’équipe de développement, après analyse détaillée de l’erreur, constate que la cause est comprise dans le modèle: en d’autres termes, il n’est pas possible de corriger l’erreur sans se livrer à des modifications majeures, touchant la structure même de l’application (modification radicale d’un circuit intégré dans un développement hardware, ou redéveloppement de 30% du code d’une application logicielle).

Démarches

La notion de démarche est importante dans le sens qu’il n’y a pas de règle préétablie dans le processus de modélisation : beaucoup d’étapes sont fortement conditionnées par l’intuition, le feeling de l’ingénieur. On peut d’ailleurs s’estimer heureux qu’il en soit ainsi !
A quoi pourrait bien servir un ingénieur si son travail pouvait être entièrement codifié, et de ce fait implémenté par le premier ordinateur venu?

Une démarche itérative et incrémentale ?
L’idée est simple : pour modéliser (comprendre et représenter) un système complexe, il vaut mieux s’y prendre en plusieurs fois, en affinant son analyse par étapes. Cette démarche devrait aussi s’appliquer au cycle de développement dans son ensemble, en favorisant le prototypage. Le but est de mieux maîtriser la part d’inconnu et d’incertitudes qui caractérisent les systèmes complexes.

Une démarche pilotée par les besoins des utilisateurs ?
Avec UML, ce sont les utilisateurs qui guident la définition des modèles (mais cela devrait en fait être le cas de toute démarche de modélisation) :
• Le périmètre du système à modéliser est défini par les besoins des utilisateurs (les utilisateurs définissent ce que doit être le système).
• Le but du système à modéliser est de répondre aux besoins de ses utilisateurs (les utilisateurs sont les clients du système).
Les besoins des utilisateurs servent aussi de fil rouge, tout au long du cycle de développement (itératif et incrémental) :
• A chaque itération de la phase d’analyse, on clarifie, affine et valide les besoins des utilisateurs.
• A chaque itération de la phase de conception et de réalisation, on veille à la prise en compte des besoins des utilisateurs.
• A chaque itération de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.

Une démarche centrée sur l’architecture ?
Une architecture adaptée est la clé de voûte du succès d’un développement. Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité…).
Ph. Kruchten propose différentes perspectives, indépendantes et complémentaires, qui permettent de définir un modèle d’architecture (publication IEEE, 1995). Cette vue (« 4+1 ») a fortement inspiré UML.

….

Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Introduction à UML (908 Ko) (Cours PDF)