Rapport
• Constatations et état du marché • Approche objet • Inconvénients et remèdes • La genèse • Le cycle itératif et incrémental
– Les diagrammes UML
• Diagramme des cas d'utilisation • Diagramme de classes, objets • Diagramme de séquence • Diagramme de collaboration • Diagramme d'états – transition • Diagramme de composants • Diagramme de déploiement
Ça va mal dans le logiciel
Seulement 15 % (chiffres 99) des applications écrites sont mises en place et fonctionnent ! (selon des enquêtes réalisées aux USA) Pourquoi ? Evolution des spécifications en cours de développement Complexité des applications Technologies en perpétuelle mutation Retards de livraisons Dépassements de budgets Manque de réactivité
L’état du Marché
• Quelle est la réalité du développement aujourd’hui ?
Est-ce que je peux partager mes systèmes existants ? Puis-je intégrer de nouvelles applications ? Quelle est l’adaptabilité de mon application (souplesse) ?
•
Le rythme effréné des changements technologiques:
Internet/Intranet, ERP CORBA , COM/DCOM, ActiveX, Java, ... Système Distribués à N-niveau
•
Etat actuel : des dépendances ingérables entre des applications peu ou pas documentées
L’approche objet : une solution ?
• Maîtrise de la complexité Une décomposition objet décrit et décompose le problème étudié comme un ensemble d’objets autonomes qui collaborent pour réaliser certaines opérations. Chaque objet décrit un certain objet du monde réel et incorpore son propre comportement. Les objets inter-agissent en s’envoyant des messages demandant l’exécution de telle ou telle opération • Réutilisation
Les inconvénients de l’approche objet
• Moins intuitive que l’approche fonctionnelle ou chaque fonction du système est identifiée puis décomposée en sous-fonctions • Dérive inévitable car rien dans les concepts de base de l’approche objet ne dicte comment modéliser la structure objet d’un système de manière pertinente • Nécessité d’une grande rigueur