La programmation orientée objet (ou POO) est née des travaux de recherche sur l'intelligence artificielle, dans les années 70-80. Elle consiste à combiner au sein d'une même structure de données, appelée Classe, opérations et données. Le concept de classe a été introduit avec le langage Simula, ceux d'encapsulation, d'héritage et de polymorphisme avec le langage Smalltalk.

Depuis, l'Objet n'a cessé d'évoluer aussi bien dans son aspect théorique que pratique et différents métiers ont vu le jour comme l'analyse objet (AOO ou OOA en anglais), la conception objet (COO ou OOD en anglais) ou base de données objet (SGBDOO). Aujourd'hui, l'Objet est beaucoup plus une approche, un paradigme, qu'une simple façon de programmer. C'est pourquoi, lorsque l'on parle de l'Objet, on le désigne plus volontiers comme approche Objet que par programmation orienté objet, ce dernier ne désignant plus que la partie codage d'un modèle objet obtenu par AOO et COO.

Dans l'approche Objet, les systèmes sont uniquement constitués d'entités appelées objet. Ces objets sont définis par des types (voir la théorie des types de Liskov et celle de Cardelli par exemple). Un type, en programmation orienté objet, définit de façon syntaxique et sémantique les propriétés que présenteront les objets (les valeurs) du type ; ces propriétés permettent de délimiter, de qualifier les objets. Il définit l'interface visible de l'objet au travers duquel on peut communiquer avec lui. L'implémentation de ces propriétés sont ensuites fournis par une classe, structure de données qui lie à une propriété une implémentation possible.

L'implémentation des propriétés par une classe peut être représentée soit sous forme d'emplacement mémoire (champs de donnée) appelé attribut, soit sous forme de calcul (opération) appelé méthode. Selon Cook (théorie F-Bound), une classe est l'implémentation d'une famille polymorphique de types ; une classe dans ce cas n'est donc pas nécessairement l'implémentation d'un seul type (cf. Langages à prototypes).

En Objet, si un type définit donc l'interface de l'objet, la classe lui fournit une implémentation. A ce titre, la classe est le moule par lequel est construit un objet. On dit alors d'un objet qu'il est une instance de telle classe. L'approche Objet introduit alors deux types d'héritage : le sous-typage (héritage d'interface) et la sous-classification (l'héritage d'implémentation). L'héritage est la faculté d'une sous-classe ou d'un sous-type d'hériter des propriétés de son parent et de les raffiner. Le sous-typage est donc le processus par lequel on restreint l'espace des valeurs du type parent, et la sous-classification est le processus par lequel on récupère et on spécialise l'implémentation.

Modélisation objet

La modélisation objet consiste à créer un modèle informatique de la problèmatique auquel on souhaite fournir une solution (un système informatique). Ce modèle peut rassembler aussi bien des élements du monde réel que des concepts ou des idées propres au métier ou au domaine duquel fera partie le système. La modélisation Objet consiste à définir, à qualifier dans un premier temps ces élements sous forme de type, donc indépendemment de l'implémentation. C'est ce que l'on appelle l'analyse orienté objet ou OOA (Object-Oriented Analysis).

Puis, on propose une ou des solutions techniques pour représenter les élements définis dans le système informatique. C'est ce que l'on appelle la conception orientée objet ou OOD (Object-Oriented Design). Une fois un modèle de conception établi, il est possible au développeur de leur donner corps dans un langage de programmation. C'est ce que l'on appelle la programmation orientée objet ou OOP (Object-Oriented Programming). A un modèle d'analyse peut correspondre plusieurs modèles de conception.

Pour écrire ces différents modèles, différents langages et méthodes ont été mises au point, dont OMT de Rumbaugh, BOOCH'93 de Booch et OOSE de Jacobson. Toutefois, ces méthodes ne permettaient de modéliser que certains types d'applications et se trouvaient limitées dans d'autres contextes. La méthode OMT prévalait sur l'ensemble des autres méthodes dans la première partie de la décennie 1990.

À partir de 1994, Rumbaugh, Booch et Jacobson ont décidé de s'unir dans l'élaboration d'une nouvelle méthode, suffisamment générique, pour pouvoir s'appliquer à quasiment tous les contextes applicatifs. Ils ont commencé d'abord par définir un langage de modélisation fortement inspiré de celles des méthodes des trois auteurs : UML (Unified Modelling Language). Une fois celui-ci pris en charge par l'OMG (Object Management Group), un organisme destiné à standardiser des technologies objet, comme CORBA (Common Object Request Broker), un middleware objet distribué, Rumbaugh, Booch et Jacobson se sont attaquées à la méthode proprement dite: USDP (Unified Software Development Process). Cette méthode définit un cadre générique de développement objet avec UML comme langage de modélisation. USDP (généralement raccourcit en UP) est une méthode itérative et incrémentale, centrée sur l'architecture et guidée par les cas d'utilisation et la réduction des risques. C'est aux concepteurs de s'attribuer cette méthode en l'instanciant à leur métier et à leur domaine.