Principes de langage orienté objet (UML)

Cours principes des langages orientés objet (UML), tutoriel & guide de travaux pratiques en pdf.

Les erreurs de cette vision des choses

Vous n’interviendrez “jamais” sur un projet totalement nouveau
Ignore les relations avec les autres applications de l’entreprise : la gestion des stocks peut communiquer avec la fabrication des marchandises, les commandes des clients . . .
cloisonne les activités : organisation hiérarchique de l’analyste au programmeur, le client n’a pas de contact avec le réalisateur final.
Un client connait pas ses besoins.
4Un système doit être facile à modifier, à enrichir de nouvelles fonctionnalités.
4L’architecture doit donc être modulaire et facile à maintenir.

Développement Orienté Objet

Conséquences de l’application des méthodes OO :
les phases d’analyse, de conception et de programmation sont très liées.
Historique des méthodes orientées objet :
1. langages de programmation,
2. méthodes de conception,
3. méthodes d’analyse.

Quelques repères

Age de l’invention :
1967 – le langage de programmation SIMULA.
1970 – SMALLTALK (Palo Alto).
Age de la confusion :
1980 – les langages ++.
Les méthodes de conception se multiplient
Age de la maturité:
1990 – Object Management Group : standardisation.
Unification des méthodes OMT (Booch) OOSE (Jacobson) et Rumbaugh : Unified Modeling Language (version 1.0 1997, version actuelle 1.3).

Principes des langages orientés objet

Permettent d’exprimer la solution d’un problème à l’aide des éléments de ce problème.
Les programmes manipulent des structures de données représentant les différentes entités, les objets, du domaine traité.
Dans ce contexte, Objet signifie élément de l’univers, c-à-d : chose palpable et/ou visible, quelque chose qui peut être appréhendée intellectuellement, quelque chose vers qui la pensée ou l’action est dirigée.
Pour la conception de logiciels, un objet représente un élément individuel, identifiable, soit réel, soit abstrait avec un rôle bien défini dans le domaine du problème.

Les concepts de base

Objets : unités de base organisées en classes et partageant des traits communs (attributs ou procédures).
Peuvent être des entités du monde réel, des concepts de l’application ou du domaine traité.
Encapsulation :
les structures de données et les détails de l’implémentation sont cachés aux autres objets du
système.
La seule façon d’accéder à l’état d’un objet est de lui envoyer un message qui déclenche l’exécution de l’une de ses méthodes.
Encapsulation :
Les types d’objets peuvent être assimilés aux types de données abstraites en programmation. Abstraction et encapsulation sont complémentaires, l’encapsulation dressant des barrières entre les différentes abstractions.
Héritage : chaque instance d’une classe d’objet hérite des caractéristiques (attributs et méthodes) de sa classe mais aussi d’une éventuelle super-classe. L’héritage est un des moyens d’organiser le monde c.-à-d. de décrire les liens qui unissent les différents objets.
Polymorphisme : possibilité de recourir à la même expression pour dénoter différentes opérations. L’héritage est une forme particulière du polymorphisme caractéristique des systèmes orientés objet.
Modularité : partition du programme qui crée des frontières bien définies (et documentées) à l’intérieur du programme dans l’objectif d’en réduire la complexité (Meyers). Le choix d’un bon ensemble de modules pour un problème donné, est presque aussi difificile que le choix d’un bon ensemble d’abstractions.

Faire des choix

• Quelles sont les caractéristiques – attributs – d’une personne ?
• Quels sont les comportements génériques – fonctions – d’une personne ?

Trouver les bons objets

Méthode de désagrégation / agrégation :
désagréger un module ) une suite de modules, agréger une suite de modules ) un module.
Désagrégation
On part d’un tout que l’on éclate en plusieurs parties. Chaque partie, formant à son tour un tout, est susceptible d’être à nouveau éclatée en parties plus petites.
Il est difficile d’exprimer en décomposition logicielle ce qu’est une partie.
La conception fait l’hypothèse que le système est un tout. Pour détailler et exprimer la solution, on postule que ce tout est composé de parties cohérentes séparables.
Dans un premier temps, la décomposition est basée sur les entités du domaine du problème.
La désagrégation est très différente de la décomposition fonctionnelle puisqu’une fonctionnalité n’est pas une entité du monde concret.
La granularité de la taille des entités à utiliser est un facteur important de l’effort d’abstraction à réaliser.
Comment faire trouver les bons Objets ?
c.-à-d. :
1) comment trouver un objet ?
2) comment distinguer un bon objet d’un mauvais ?

Quelques règles d´écriture d’un module

Un module représente un concept et tout le concept.
Pour représenter une idée, il faut que cette idée existe.
Ne pas regrouper dans un module des opérations qui n’ont pas de raisons particulières d’être ensemble (écriture de modules fourre-tout).
Pour concrétiser une idée le choix du nom du module est un élément puissant d’expression (exemple les design patterns).
Dans une première phase “simpliste” le choix des méthodes correspond aux verbes.

La visibilité des attributs et des méthodes

Publique : un attribut ou une méthode publique est spécifée avec le signe +.
Privée : un attribut ou une méthode privée est spécifée avec le signe -.
Protected : un attribut ou une méthode protégée est spécifée avec le signe #.

Signature

La signature d’une méthode se compose de :
son nom,
le nombre et le type de ses paramètres en entrée,
Exemple :
public void afficher(String , Integer);
Dans un espace défini (le même espace de noms), deux méthodes peuvent avoir le même nom si elles n’ont pas la même signature.