Les méthodes fonctionnelles (également qualifiées de méthodes structurées) trouvent leur origine dans les langages procéduraux. Elles mettent en évidence les fonctions à assurer et proposent une approche hiérarchique descendante et modulaire.
Ces méthodes utilisent intensivement les raffinements successifs pour produire des spécifications dont l’essentielle est sous forme de notation graphique en diagrammes de flots de données. Le plus haut niveau représente l’ensemble du problème (sous forme d’activité, de données ou de processus, selon la méthode). Chaque niveau est ensuite décomposé en respectant les entrées/sorties du niveau supérieur. La décomposition se poursuit jusqu’à arriver à des composants maîtrisables (cf. figure 1.3).
L’approche fonctionnelle dissocie le problème de la représentation des données, du problème du traitement de ces données. Sur la figure 1.3, les données du problème sont représentées sur la gauche. Des flèches transversalles matérialisent la manipulation de ces données par des sous-fonctions. Cet accès peut-être direct (c’est parfois le cas quand les données sont regroupées dans une base de données), ou peut être réalisé par le passage de paramètre depuis le programme principal.
La SADT (Structured Analysis Design Technique) est probablement la méthode d’analyse fonctionnelle et de gestion de projets la plus connue. Elle permet non seulement de décrire les tâches du projet et leurs interactions, mais aussi de décrire le système que le projet vise à étudier, créer ou modifier, en mettant notamment en évidence les parties qui constituent le système, la finalité et le fonctionnement de chacune, ainsi que les interfaces entre ces diverses parties. Le système ainsi modélisé n’est pas une simple collection d’éléments indépendants, mais une organisation structurée de ceux-ci dans une finalité précise.
En résumé, l’architecture du système est dictée par la réponse au problème (i.e. la fonction du système).
L’approche orientée objet considère le logiciel comme une collection d’objets dissociés, identifiés et possédant des caractéristiques. Une caractéristique est soit un attribut (i.e. une donnée caractérisant l’état de l’objet), soit une entité comportementale de l’objet (i.e. une fonction). La fonctionnalité du logiciel émerge alors de l’interaction entre les différents objets qui le constituent. L’une des particularités de cette approche est qu’elle rapproche les données et leurs traitements associés au sein d’un unique objet.
Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :
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, personne, …) ou bien virtuelle (client, temps, …).
La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures logicielles fondées sur les objets du système, plutôt que sur la fonction qu’il est censé réaliser.
En résumé, l’architecture du système est dictée par la structure du problème.
Selon la thèse de Church-Turing, tout langage de programmation non trivial équivaut à une machine de Turing. Il en résulte que tout programme qu’il est possible d’écrire dans un langage pourrait également être écrit dans n’importe quel autre langage. Ainsi, tout ce que l’on fait avec un langage de programmation par objets pourrait être fait en programmation impérative. La différence entre une approche fonctionnelle et une approche objet n’est donc pas d’ordre logique, mais pratique.
L’approche structurée privilégie la fonction comme moyen d’organisation du logiciel. Ce n’est pas pour cette raison que l’approche objet est une approche non fonctionnelle. En effet, les méthodes d’un objet sont des fonctions. Ce qui différencie sur le fond l’approche objet de l’approche fonctionnelle, c’est que les fonctions obtenues à l’issue de la mise en œuvre de l’une ou l’autre méthode sont distinctes. L’approche objet est une approche orientée donnée. Dans cette approche, les fonctions se déduisent d’un regroupement de champs de données formant une entité cohérente, logique, tangible et surtout stable quant au problème traité. L’approche structurée classique privilégie une organisation des données postérieure à la découverte des grandes, puis petites fonctions qui les décomposent, l’ensemble constituant les services qui répondent aux besoins.
En approche objet, l’évolution des besoins aura le plus souvent tendance à se présenter comme un changement de l’interaction des objets. S’il faut apporter une modification aux données, seul l’objet incriminé (encapsulant cette donnée) sera modifié. Toutes les fonctions à modifier sont bien identifiées : elles se trouvent dans ce même objet : ce sont ses méthodes. Dans une approche structurée, l’évolution des besoins entraîne souvent une dégénérescence, ou une profonde remise en question, de la topologie typique de la figure 1.3 car la décomposition des unités de traitement (du programme principal aux sous-fonctions) est directement dictée par ces besoins. D’autre part, une modification des données entraîne généralement une modification d’un nombre important de fonctions éparpillées et difficiles à identifier dans la hiérarchie de cette décomposition.
En fait, la modularité n’est pas antinomique de l’approche structurée. Les modules résultant de la décomposition objet sont tout simplement différents de ceux émanant de l’approche structurée. Les unités de traitement, et surtout leur dépendance dans la topologie de la figure 1.3 sont initialement bons. C’est leur résistance au temps, contrairement aux modules objet, qui est source de problème. La structure d’un logiciel issue d’une approche structurée est beaucoup moins malléable, adaptable, que celle issue d’une approche objet.
Ainsi la technologie objet est la conséquence ultime de la modularisation du logiciel, démarche qui vise à maîtriser sa production et son évolution. Mais malgré cette continuité logique les langages objet ont apporté en pratique un profond changement dans l’art de la programmation : ils impliquent en effet un changement de l’attitude mentale du programmeur.
Dans la section 1.3.2, nous avons dit que l’approche objet rapproche les données et leurs traitements. Mais cette approche ne fait pas que ça, d’autres concepts importants sont spécifiques à cette approche et participent à la qualité du logiciel.
Tout d’abord, introduisons la notion de classe. Une classe est un type de données abstrait qui précise des caractéristiques (attributs et méthodes) communes à toute une famille d’objets et qui permet de créer (instancier) des objets possédant ces caractéristiques. Les autres concepts importants qu’il nous faut maintenant introduire sont l’encapsulation, l’héritage et l’agrégation.
L’encapsulation consiste à masquer les détails d’implémentation d’un objet, en définissant une interface. L’interface est la vue externe d’un objet, elle définit les services accessibles (offerts) aux utilisateurs de l’objet.
L’encapsulation facilite l’évolution d’une application car elle stabilise l’utilisation des objets : on peut modifier l’implémentation des attributs d’un objet sans modifier son interface, et donc la façon dont l’objet est utilisé.
L’encapsulation garantit l’intégrité des données, car elle permet d’interdire, ou de restreindre, l’accès direct aux attributs des objets.
L’héritage est un mécanisme de transmission des caractéristiques d’une classe (ses attributs et méthodes) vers une sous-classe. Une classe peut être spécialisée en d’autres classes, afin d’y ajouter des caractéristiques spécifiques ou d’en adapter certaines. Plusieurs classes peuvent être généralisées en une classe qui les factorise, afin de regrouper les caractéristiques communes d’un ensemble de classes.
Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies de classes. L’héritage peut être simple ou multiple. L’héritage évite la duplication et encourage la réutilisation.
Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des objets de classes différentes. Le polymorphisme augmente la généricité, et donc la qualité, du code.
Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une classe sont des composants de l’autre classe. Une relation d’agrégation permet donc de définir des objets composés d’autres objets. L’agrégation permet donc d’assembler des objets de base, afin de construire des objets plus complexes.
Les premiers langages de programmation qui ont utilisé des objets sont Simula I (1961-64) et Simula 67 (1967), conçus par les informaticiens norvégiens Ole-Johan Dahl et Kristan Nygaard. Simula 67 contenait déjà les objets, les classes, l’héritage, l’encapsulation, etc.
Alan Kay, du PARC de Xerox, avait utilisé Simula dans les années 1960. Il réalisa en 1976 Smalltalk qui reste, aux yeux de certains programmeurs, le meilleur langage de programmation par objets.
Bjarne Stroustrup a mis au point C++, une extension du langage C permettant la programmation orientée objets, aux Bell Labs d’AT&T en 1982. C++ deviendra le langage le plus utilisé par les programmeurs professionnels. Il arrivera à maturation en 1986, sa standardisation ANSI / ISO date de 1997.
Java est lancé par Sun en 1995. Comme il présente plus de sécurité que C++, il deviendra le langage favori de certains programmeurs professionnels.
