Analyse et Conception de Systmes Orients Objet

Ibrahima GUEYE

Ibrahima82.gueye@ucad.edu.sn Chercheur en Informatique Ingnieur Dveloppeur

Unified Modelling Language

Objectifs du cours
Ingnierie du logiciel

Principes et objectifs
Modlisation avec UML(Unified Modelling

Language) Comprendre les concepts cls de lapproche oriente objet. Savoir aborder un problme en se basant sur une approche oriente objet. Matriser les principaux diagrammes UML qui permettent de concevoir un systme 2

Unified Modelling Language

Motivations
Systmes dinformation dune entreprise est compos

de matriels et de logiciels.
80 % de logiciel 20 % de matriel

Depuis quelques annes, la fabrication du matriel

est assure par quelques fabricants seulement

Le matriel est relativement fiable Le march est standardis

Les problmes lis linformatique sont

essentiellement des problmes de Logiciel

3

Unified Modelling Language

Objectifs du Gnie Logiciel (GL)

Rpondre un problme caus:
le logiciel ntait pas fiable, il tait incroyablement difficile de raliser dans des

dlais prvus des logiciels satisfaisant un cahier de charges.

Optimiser le cot de dveloppement du logiciel
Comment faire des logiciels de qualits? Quelles mtriques pour jauger la qualit dun

logiciel?
4

Unified Modelling Language

Quelques principes du GL
Gnralisation regroupement dun ensemble de fonctionnalits

semblables en une fonctionnalit paramtrable (gnricit, hritage)

Structuration faon de dcomposer un logiciel (utilisation dune

mthode bottom-up ou top-down)

Abstraction mcanisme qui permet de prsenter un contexte en

exprimant les lments pertinents et en omettant ceux qui ne le sont pas.

5

Unified Modelling Language

Qualits dun logiciel (1/9)

Utilit:

Adquation entre le besoin effectif de

lutilisateur et les fonctionnalits offertes par le logiciel

Comment y parvenir?
Communication avec lutilisateur: en

amont, durant et en aval Via un langage comprhensible Travail avec rigueur et avec abstraction
6

Unified Modelling Language

Qualits dun logiciel (2/9)

Utilisabilit:
Efficacit, convivialit et satisfaction avec laquelle les

utilisateurs accomplissent des tches dans un environnement particulier

Facilit dapprentissage Comprendre ce que lon peut faire avec le logiciel et savoir

le faire Documentation bien rdige

Facilit dutilisation Importance de leffort ncessaire pour interagir avec le

logiciel
Comment atteindre ce but? Analyser le mode opratoire des utilisateurs Adapter lergonomie du logiciel aux utilisateurs.

Unified Modelling Language

Qualits dun logiciel (3/9)

Fiabilit: Justesse, conformit Le logiciel est conforme sa spcification, les rsultats sont ceux escompts Robustesse, sret Le logiciel fonctionne convenablement en toutes circonstances, rien de catastrophique ne peut survenir mme en dehors des conditions dutilisations prvues.
Solutions Utiliser des mthodes formelles, langage de

programmation de haut niveau quipement matriel de qualit Vrification et tests (version alpha ou bta)

Unified Modelling Language

Qualits dun logiciel (4/9)

Interoprabilit et compatibilit: Un logiciel doit pouvoir interagir en synergie

avec dautres logiciels

Solutions Bases de donnes (indpendance

donnes/traitements) Externaliser certaines tches en utilisant des middlewares Utiliser des formats standards (XML) et des protocoles de communication normaliss (Corba)
9

Unified Modelling Language

Qualits dun logiciel (5/9)

Performance: Les logiciels doivent satisfaire aux

contraintes de temps dexcution, de dbit, exactitude et compltude des rponses

Solutions
Logiciels simples Veiller la complexit des algorithmes et

leur validit Machines plus performantes

10

Unified Modelling Language

Qualits dun logiciel (6/9)

Portabilit: Un logiciel doit pouvoir fonctionner sur plusieurs plateformes Indpendance avec le systme dexploitation Indpendance avec le matriel (plus difficile) Compiler avec 32 bits et excuter sur 64 bits nest pas trivial
Solutions Rendre le logiciel le plus possible indpendant de

son environnement dexcution Machines virtuelles

11

Unified Modelling Language

Qualits dun logiciel (7/9)

Rutilisabilit: Rutiliser du code existant Applications, base de donnes, Rendre le code rutilisable Modulaire, changeable,
Solutions Abstraction, gnricit (ex: MCD gnrique de

gestion stock) Construire des logiciels partir de composants Design pattern

12

Unified Modelling Language

Qualits dun logiciel (8/9)

Facilit de maintenance:

La maintenance absorbe une trs grande

partie des efforts

Maintenance corrective: corriger les

erreurs Maintenance adaptative: ajuster le logiciel en fonction de lvolution de son environnement Maintenance perfective: accrotre/amliorer les possibilits du 13 logiciels

Unified Modelling Language

Qualits dun logiciel (9/9)

Facilit de maintenance: Objectifs Rduire la quantit de maintenance corrective Rendre moins coteuse les autres maintenances
Solutions
Rutilisabilit Vrification, tests Structures de donnes complexes et algos

simples Anticiper les changements venir

14

Phases de ralisation dun systme dinformation

Unified Modelling Language

Phases de dveloppement
Le cycle de dveloppement classique comporte cinq

tapes:
Analyse des besoins: Dterminer les

fonctionnalits que doivent possder le logiciel Analyse: dterminer les tches et les structures qui se rptent dans le problme Conception: saccorder sur la manire dont le systme doit tre construit. Implmentation: Codage du rsultat de la conception. Test: Le systme est-il conforme au cahier des charges
16

Unified Modelling Language

Analyse des besoins

Capturer les besoins des clients.

clarifier, filtrer et organiser les besoins, ne

pas chercher lexhaustivit. Dlimiter les frontires du systme. Spcifier le quoi fait par le logiciel. tudier la faisabilit du projet Faisabilit organisationnelle. Faisabilit technique. Faisabilit temporelle Faisabilit financire
17

Unified Modelling Language

Analyse
Analyse du domaine: identifier les lments du

domaine ainsi que les relations et interactions entre ces lments.

Analyse de lexistant: dterminer les fonctions

principales et rutilisables du systme existant.

Analyse organisationnelle: dterminer la structure

de lorganisation actuelle.
Analyse technique: recenser les quipements

informatiques en place.
18

Unified Modelling Language

Conception
Dfinir larchitecture du logiciel
Dfinir chaque constituant du logiciel Informations traites Oprations effectues Rsultats fournis Contraintes respecter Optimiser les modles Choisir un langage de programmation
19

Unified Modelling Language

Implmentation
Cration des modules et des bases de

donnes Un module pour raliser une fonctionnalit donne Adaptation et/ ou modification des modules existants
Intgration des diffrents modules.
20

Unified Modelling Language

Tests
Tests unitaires: permettent de vrifier que chaque

module fonctionne correctement indpendamment des autres. Tests dintgration: permettent de vrifier que tous les programmes tests individuellement fonctionnent bien ensemble.
Tests systmes: permettent de vrifier que le

systme fonctionne correctement dans les conditions relles dutilisation. Tests Alpha: faire tester le logiciel par le client sur le site de dveloppement Tests Bta: faire tester le logiciel par le client sur le21

Comment russir un logiciel?

Unified Modelling Language

Utiliser des mthodes

Objectifs Spcifier et planifier les tapes de lanalyse et de la

conception.
Composition: une dmarche: explique la procdure suivre en

exploitant au mieux les principes de modularit, dabstraction, de rutilisation, etc. un formalisme de reprsentation: facilite la communication, lorganisation et la vrification.
des modles: facilitent les retours sur la conception

et lvolution des applications.

23

Unified Modelling Language

Notions de modle
Cest une reprsentation abstraite et simplifie

(i.e. qui exclut certains dtails) dune entit (phnomne, processus, systme, etc.) du monde rel en vue de le dcrire, de lexpliquer ou de le prvoir. Il est synonyme de thorie, mais avec une connotation pratique : cest une thorie oriente vers laction quelle doit servir. Il permet de rduire la complexit dun phnomne en liminant les dtails qui ninfluencent pas son comportement de manire significative. Il reflte ce que le concepteur croit important pour la comprhension et la prdiction du phnomne modlis. 24

Unified Modelling Language

exemples de modles prdictifs

Modle mtorologique: partir de donnes

dobservation (satellite . . .), il permet de prvoir les conditions climatiques pour les jours venir. Modle conomique: peut par exemple permettre de simuler lvolution de cours boursiers en fonction dhypothses macroconomiques (volution du chmage, taux de croissance . . .). Modle dmographique: dfinit la composition dun panel dune population et son comportement, dans le but de fiabiliser des tudes statistiques, daugmenter limpact de dmarches commerciales, etc.
25

Unified Modelling Language

Mthodes danalyse et de conception

Elles fournissent une mthodologie et des notations

standards qui aident concevoir des logiciels de qualit Il existe de nombreuses mthodes: Mthodes fonctionnelles: hirarchie de fonction
SADT, SA-SD, etc.

Mthodes systmiques: sparation des donnes

et des traitements.
Merise, Entit Relation, etc.

Mthodes objets: intgration des donnes et des

traitements dans un objet unique.

OMT, OOSE, etc.
26

Unified Modelling Language

Trop de Mthodes orientes objets

Entre 89 et 94 : le nombre de mthodes orientes

objet est pass de 10 plus de 50

Toutes les mthodes avaient pourtant dnormes

points communs (objets, mthode, paramtres, ) Rumbaugh ont chacun commenc adopter les ides des autres. Les 3 auteurs ont souhait crer un langage de modlisation unifi

Au milieu des annes 90, G. Booch, I. Jacobson et J.

27

Historique
Standardisation par lOMG Soumission lOMG

UML 2.0 UML 1.x UML 1.2

1999-2002
Juin 1998 Novembre 1997 Septembre 1997

Standardisation par lOMG Soumission lOMG Soumission lOMG Version bta OOPSLA96 OOPSLA95

UML 1.1 UML 1.0 UML 0.9 Mthode unifie 0.8 Booch93 OMT-2 OMT-1 OOSE

Janvier 1997
Juin 1996 Octobre 1995

Autres mthodes
28

Booch91

Partenaires

Unified Modelling Language

Aujourdhui
UML est le langage de modlisation orient objet le

plus connu et le plus utilis au monde UML sapplique plusieurs domaines UML nest pas une mthode Peu dutilisateurs connaissent le standard, ils ont une vision outille dUML (Vision Utilisateur)
5% forte comprhension, 45% faible comprhension, 50%

aucune comprhension

UML est fortement critiqu car pas assez formel Le march UML est important et saccrot MDA, UML2.0, IBM a rachet Rational !!!

29