Accueil
Documents
OOP, UML et RUP

Partie 2: Métodologies et Unified Process

Sommaire
Partie 1: OOP, OOP, vocabulaire, et UML Partie 2: Métodologies et Unified Process Partie 3: Résumé, aller plus loin, et commentaires

Méthodologie de programmation

Pourquoi utiliser une méthodologie de développement logiciel

Même si l'on sait ce qu'est un objet, une class et comment on est sensé s'en servir, le faire reste difficile. C'est encore plus dur si vous avez l'habitude de programmer de façon traditionnelle, pire même avec un processus par cascade. Rappelez-vous qu'on peut très bien programmer en C++ avec des classes sans jamais faire de la programmation objet (c'est ce qui fait de C++ un langage orienté objet et non un langage objet).

Une méthodologie de développement logiciel (development process ou programming methodology) c'est une démarche à suivre afin de créer des classes avec leurs attributs, leurs méthodes et les relations entre celle-ci pour réaliser une application spécifique. Elles permettent d'augmenter grandement la productivité, d'estimer le temps de développement, de créer des applications plus robustes - domaine de l'assurance qualité logicielle qui font souvent partie intégrante de ces méthodologies.

Quand on a aucune méthode on programme on rencontre les mêmes problèmes qu'avec la modèle cascade (mais avec encore plus de problèmes). Nous allons voir deux méthodes: La première ancienne, la seconde nettement plus récente.

Le modèle cascade: Un modèle rapidement problématique

On fait d'abord l'analyse, puis le design du logiciel complet. On décrit pas à pas tout le logiciel en partant des besoins utilisateurs jusqu'aux détails de chaque classe. Cette méthode peut aussi être appliquée pour la programmation traditionnelle. En bref: On document tout parfaitement, puis on code après.

Cette méthode suppose que l'on a rien oublié au départ et que ce que l'on aurait pu oublier n'aura guère d'influence. Elle suppose aussi que tout va bien se passer comme sur le plan. Un peu comme quand on construit une maison et qu'au final on a bien ce qu'on a planifié avec juste trois retouches à faire. Tous les documents qui définissent l'étape précédente sont considérés comme gelés (et ne sont modifié qu'en cas de problème majeur).

Il se trouve que la programmation reste encore bien trop proche d'un art sans moyens de vérifier mathématiquement (sauf si on prend un temps tellement énorme que seuls les militaires le font). A la différence de nos amis ingénieurs, en physique par exemple, nous n'avons pas encore véritablement d'outil pour vérifier que cela va bien fonctionner. Le résultat est flagrant: On passe 90% du temps pour les premier 90% du projet, et 90% pour les 10% restant. Tous les problèmes arrivent à la fin avec des problèmes qui nécessitent une retouche parfois de l'architecture du logiciel complet. Cela induit des bogues en plus qu'il faudra recorriger et ainsi de suite.

Le modèle itératif: Principes et avantages

Toutes les méthodologies de programmation actuelles sont fondées sur une approche itérative. Cela signifie qu'on prend une partie des éléments du logiciels et qu'on en fait l'analyse, le design, l'implémentation, jusqu'à compiler le tout. Ensuite on prend une autre partie et on fait de même. Même si je résume ici beaucoup, c'est le principe dont il faut se rappeler.

Les résultats sont là. On fait face aux risques et l'on les résout bien plus tôt dans la phase de développement. On peut ainsi planifier le reste de projet de façon plus précise et le logiciel complet gagne en robustesse aussi.

Unified Process: Une méthodologie de développement logiciel

Maintenant que nous avons un avant goût des avantages des méthodologies itératives, voyons-en une de plus près.

Qu'est-ce le UP/RUP?

L'Unified Process (UP) (aussi appelé Rational Unified Process ou RUP car ils sont quasi identiques) est la méthodologie actuellement le plus en vogue avec les méthodes Agile. Elle utilise une approche itérative et elle est fondée sur les Best practices (meilleures pratiques).

L'ensemble des méthodes Agile sont plus spécialisées dans les projets en petite ou moyenne équipes, mais elles peuvent venir se greffer à RUP (cela donne AUP). RUP reste de loin le plus utilisé et le plus adapté pour les très gros projets, cependant il est possible de l'utiliser même si l'on développe seul dans son grenier. Je vous invite quand même à utiliser plutôt AUP (Agile Unified Process) pour cela.

Un aperçus de UP

Nous avons parlé d'itérations, voici le moment de voir ce qu'UP nous propose de faire à chaque itération:

Durant l'itération initiale on va faire dans l'ordre chaque discipline: La modélisation du business, les exigences, l'analyse puis le design, l'implémentation, les tests, le déploiement... Une fois qu'on a fini, on passe à l'itération suivante (la colonne suivante). Il n'est pas obligatoire de faire tous les éléments. Sur le graphique ci-dessus, on voit un aperçus de la quantité de travail à fournir dans chaque domaine au cours des différentes itérations.

RUP est délimité en 4 phases que l'on exécute dans l'ordre: Genèse, élaboration, construction, transition. Lorsqu'on a fini une itération et que certains éléments sont validés on peut parfois passer à la phase suivante. Rappelez-vous que pour chaque phase on exécute des itérations, et pour chaque itération on exécute l'ensemble des disciplines (chaque ligne du graphique).

Nous allons de façon très succincte voir les disciplines d'analyse et de design.

Analyse

On fait un diagramme UML de case d'utilisation ou simplement un document texte. Un cas d'utilisation est un scénario qui va répondre au besoin d'un ou plusieurs acteurs (par exemple le client).

Pour chaque cas d'utilisation on va décrire dans l'ordre le scénario de ce qu'il se passe dans le langage du business en question. Par exemple:

L'utilisateur donne sa carte et entre son code secret.
Le système valide le code. (alternatif: le code est invalide, la carte est rejetée)
L'utilisateur entre le montant.
Le système vérifie le solde, fourni l'argent et rend la carte.

On cherche les noms dans la description de notre cas d'utilisation à analyser. Chaque nom est un objet possible. On filtre pour ne garder que de vrais objets et on en décrit les attributs dans un diagramme de classe. On fait aussi un diagramme de séquence pour notre cas d'utilisation, voir d'autres diagrammes.

Dans l'ordre en résumé:

Identifier les acteurs et les cas d'utilisation
Construire le modèle de cas d'utilisation
Décrire la suite d'événements principale menant au succès
Identifier les relations
Décrire les suites d'événements alternatifs
Trouver les objets potentiels (regarder dans les noms)
Sélectionner les objets proposés (supprimer: synonymes, hors propos, rôles, non-unique, vague, actions ou attributs)

Design

On transforme les cas d'utilisations à traiter de cas d'utilisation d'analyse en cas d'utilisation de design. Cela veut dire qu'on décrit très en détail ce que l'utilisateur fait et les réponses du système. Par exemple: "L'utilisateur entre son code et valide" devient "L'utilisateur appuis dans l'ordre sur les touches du clavier numérique pour entrer son code et valide en appuyant sur la touche VALIDER".

On regarde si on rajoute des objets, puis on regarde pour les verbes cette fois. Chaque verbe est une responsabilité d'un objet possible. On filtre les verbes pour retirer ceux qui sont effectués manuellement par l'utilisateur puis on classifie les autres (Entity/Boundary/Control). On cherche l'objet qui est responsable et les collaborateurs nécessaires. Ainsi on obtient nos méthodes.