LE DIDACTICIEL (suite 2)

LES DIFFERENTES METHODES D’ANALYSE DE SYSTEME D’INFORMATION

            UML (Unified Modeling Language, que l’on peut traduire par “langage de modélisation unifié) est une notation permettant de modéliser un  problème de façon standard. Ce langage est né de la fusion de plusieurs méthodes existantes auparavant, et est devenu désormais la référence en terme de modélisation objet, à un tel point que sa connaissance est souvent nécessaire pour obtenir un poste de développement objet.

LA NOTION D’OBJET

            La programmation orientée objet consiste à modéliser informatiquement un ensemble d’éléments d’une partie du monde réel (que l’on appelle domaine) en un ensemble d’entités informatiques. Ces entités informatiques sont appelées objets. Il s’agit de données informatiques regroupant les principales caractéristiques des éléments du monde réel (taille, couleur, …).

La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d’objets, d’entités ayant une existence matérielle (chien, voiture, ampoule, …) ou bien virtuelle (sécurité sociale, temps, …).

LES METHODES OBJETS

            La modélisation objet consiste à créer une représentation informatique des éléments du monde réel auxquels on s’intéresse, sans se préoccuper de l’implémentation, ce qui signifie indépendamment d’un langage de programmation. Il s’agit donc de déterminer les objets présents et d’isoler leurs données et les fonctions qui les utilisent. Pour cela des méthodes ont été mises au point. Entre 1970 et 1990, de nombreux analystes ont mis au point des approches orientées objets, si bien qu’en 1994 il existait plus de 50 méthodes objet. Toutefois seules 3 méthodes ont véritablement émergé :

Ø  La méthode OMT de Rumbaugh

Ø  La méthode BOOCH^’93 de Booch

Ø  La méthode OOSE de Jacobson (Objet Oriented Software Engineering)

A partir de 1994, Rumbaugh et Booch (rejoints en 1995 par Jacobson) ont unis leurs efforts pour mettre au point la méthode unifiée (Unified method 0.8), incorporant les avantages de chacune des méthodes précédentes.

La méthode unifiée à partir de la version 1.0 devient UML (Unified Modeling Language), une notation universelle pour la modélisation objet.

UML n’est pas une méthode dans la mesure où elle ne présente aucune démarche.  A ce titre UML est un formalisme de modélisation objet. Le mot méthode parfois utilisé par abus de langage dans les pages suivantes ne doit  donc pas être entendu comme un “démarche“.

            UML 1.0 est soumise à l’OMG (Objet Management Group) en janvier 1997, mais elle ne sera acceptée qu’en  novembre 1997 dans sa version 1.1, date à partir de laquelle UML devient un standard international.

Le récapitulatif des évolutions de ce langage de modélisation :  

Ø  En 1995 : Méthode unifiée 0.8 (intégrant les méthodes Booch^’93 et OMT)

Ø  En 1995 : UML 0.9 (intégrant la méthode OOSE)

Ø  En 1996 : UML 1.0 (proposée à l’OMG)

Ø  En 1997 : UML 1.1 (standardisée par l’OMG)

Ø  En 1998 : UML 1.2

Ø  En 1999 : UML 1.3

Ø  En 2000 : UML 1.4

Ø  En 2003 : UML 1.5

Les dernières versions des spécifications peuvent être téléchargées sur le site de l’OMG.

Cette méthode représente un moyen de spécifier, de représenter et de construire les composantes d’un système informatique. Avec la méthode UML, un objet est par exemple représenté de la façon suivante :

INTÉRET D’UNE MÉTHODE OBJET

            Les langages orientés objet constituent chacun une manière spécifique d’implémenter le paradigme objet. Ainsi, une méthode objet permet de définir le problème à haut niveau sans rentrer dans les spécificités d’un langage. Il représente ainsi un outil permettant de définir un problème de façon graphique, afin par exemple de le présenter à tous les acteurs d’un projet (n’étant pas forcément des experts en un langage de programmation).

            De plus, le fait de programmer à l’aide d’un langage orienté objet ne fait pas d’un programmeur un concepteur objet. En effet il est tout à fait possible de produire un code syntaxiquement juste sans pour autant adopter une approche objet. Ainsi la programmation orientée objet implique :

Ø  En premier lieu une conception abstraite d’un modèle objet (c’est le rôle de la méthode objet) en second plan l’implémentation à l’aide d’un langage orienté objet (tel que C++/Java/…)

Une méthode objet est donc d’une part une méthode d’analyse du problème (afin de couvrir toutes les facettes du problème), d’autre part un langage permettant une représentation standard stricte des concepts abstraits (la modélisation) afin de constituer un langage commun.

LA NORMALISATION OMG

            Ainsi, il est nécessaire qu’une méthode objet soit définie de manière rigoureuse et unique afin de lever les ambiguïtés. De nombreuses méthodes objet ont été définies, mais aucune n’a su s’imposer en raison du manque de standardisation. C’est pourquoi l’ensemble des acteurs du monde informatique a fondé en 19889 l’OMG (Object Management Group), une organisation à but non lucratif, dont le but est de mettre au point des standards garantissant la compatibilité entre des applications programmées à l’aide de langage objet et fonctionnant sur des réseaux hétérogènes (de différents types).

            A partir de 1997, UML est devenue une norme de l’OMG, ce qui lui a permis de s’imposer en tant que méthode de développement objet et être reconnue et utilisée par de nombreuses entreprises.

UML EST BASÉE SUR UN MÉTA MODÈLE

            UML est un moyen d’exprimer des modèles objet en faisant abstraction de leur implémentation, c’est-à-dire que le modèle fourni par UML est valable pour n’importe quel langage de programmation. UML est un langage qui s’appuie sur un méta modèle, un modèle de plus haut niveau qui définit les éléments d’UML (les concepts utilisables) et leur sémantique (leur signification et leur mode d’utilisation). Le méta modèle permet de se placer à un niveau d’abstraction supérieur car il est étudié pour être plus générique que le modèle qu’il permet de construire. Le méta modèle d’UML en fait un langage formel possédant les caractéristiques suivantes :

ü  Un langage sans ambiguïtés

ü  Un langage universel pouvant servir de support pour tout langage orienté objet

ü  Un moyen de définir la structure d’un programme

ü  Une représentation visuelle permettant la communication entre les acteurs d’un même projet

ü  Une notation graphique simple, compréhensible même par des non informaticiens

Le méta modèle permet de donner des bases solides et rigoureuses à ce langage graphique, dont les représentations graphiques ne sont là que pour véhiculer les concepts de réalisation.

UML COMME VISUALISATION COMPÈLTE D’UN SYSTÈME

            UML offre de manière élégante de représenter le système selon différentes vues complémentaires grâce aux diagrammes. UML permet d’économiser de l’argent. Lorsqu’une entreprise désire un logiciel, elle réalise parfois en interne, mais le fait plus généralement réaliser par une société de services. Dans un cas comme dans l’autre il est nécessaire de définir l’ensemble des fonctionnalités que le logiciel doit posséder. Le demandeur du logiciel n’a parfois pas de compétences particulières en informatique et exprime donc ses souhaits sous forme d’un CdCF (Cahier des Charges Fonctionnelles), c’est-à-dire un document décrivant sous forme textuelle l’ensemble des particularités que le logiciel doit posséder, les conditions qu’il doit remplir (système(s) d’exploitation visé(s)), les écueils à éviter, ainsi que les délais impartis, éventuellement les clauses sur le cout, les langages à utiliser, …

Le CdCF est ainsi distribué à différentes sociétés de services (dans le cas d’une sous-traitance) sous forme d’un appel d’offre, auquel les sociétés vont répondre par un cout, un délai, …  lorsqu’une société obtient le marché et qu’elle décide (si elle a le choix) d’opter pour un langage orienté objet, il lui faut dans un premier temps créer un modèle (c’est là qu’intervient UML) afin :

ü  De présenter au client la façon suivant laquelle elle compte développer le logiciel

ü  D’accorder tous acteurs du projet (une application de grande envergure est généralement réalisée par modules développés par différentes équipes)

Ainsi, si le modèle ne convient pas au client, il sera “simple“ à modifier, contrairement à une application directement implémentée (qui aurait mobilisée beaucoup plus de personnel, pendant une période plus longue), ce qui signifie une perte d’argent beaucoup moins importante pour la société de services, ainsi qu’un meilleure probabilité de rendre dans les temps (on parle généralement de deadline) une application conforme aux exigences du client (si l’application se conforme au modèle présenter au client, celui-ci peut difficilement contester la validité du logiciel).