Upload
others
View
19
Download
0
Embed Size (px)
Citation preview
Conception Orientée Objet
UML 2
Année 2016 – 2017
PLAN
• Notions sur le Génie Logiciel (GL)
• Concepts de l'approche objet
• UML
– Diagrammes statiques (structurels)
– Diagrammes comportementaux
2 COURS CONCEPTION ORIENTÉE OBJET – UML2
REFERENCES • Introduction au Génie logiciel. Jean-Paul Rigault. 2005/2006
http://users.polytech.unice.fr/~jpr/Enseignement/dokuwiki/doku.php?id=gbio:uml_gl
• Gestionde projet/ GÉNIE Logiciel. Jean-Charles Régin, Licence Informatique
3ème année – MIAGE.
http://deptinfo.unice.fr/~regin/cours/cours/GestionProjet/gprojet.htm
• Génie Logiciel. Laurent TICHIT - Noël NOVELLI.
http://www.dil.univ-mrs.fr/~novelli/GL/COURS/
• Cours de Génie Logiciel. S. Mouline. Départ de Mathématiques et
Informatique. FSR. Université Mohamed V.
• Activités et modèles de développement en génie logicel. Bernard
ESPINASSE.
• Génie logiciel avancé. Delphine Longuet. Université Paris-Sud.
• Analyse et conception orientées objet. Emmanuel Polonowski. Université
Paris-Est Créteil.
• Bases de la conception orientée objet. Petru Valicov.
• http://www.commentcamarche.net/contents/477-methodes-agiles-rad-xp
• https://www.youtube.com/watch?v=GWIab0yDj5A
• http://erichmusick.com/writings/technology/1992-london-ambulance-cad-
failure.html
• https://en.wikipedia.org/wiki/London_Ambulance_Service
• https://en.wikipedia.org/wiki/Denver_International_Airport#Automated_b
aggage_system
3 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL (GL)
Logiciel ?
Des petits Détails qui ont fait le bug
Pourquoi Le logiciel est il sujet aux bugs ?
Quelques Chiffres – BILAN
Génie Logiciel
Origine
Buts
Définitions
Passage de la programmation "in the small" à la
programmation "in the large"
Nature des Coûts
Facteurs de réussite
Qualité
Processus de développement du logiciel
COURS CONCEPTION ORIENTÉE OBJET – UML2 4
LOGICIEL ?
• Ensemble des programmes, procédés et règles, et
éventuellement de la documentation, relatifs au
fonctionnement d'un ensemble de traitement de données. (Par
opposition au matériel.) [LAROUSSE; Dictionnaire de
français]
• Ensemble d'entités nécessaires au fonctionnement d'un
processus de traitement automatique de l'information:
Programmes, données, documentation...
COURS CONCEPTION ORIENTÉE OBJET – UML2 5
NOTIONS SUR LE GÉNIE LOGICIEL
• En 1947, un « calculateur programmable » Mark II de
l’université de Harvard s'arrête brutalement.
Cause: BUG (insecte [Fr]).
"Un papillon mort avait provoqué un court-circuit".
• Passage d'une sonde spatiale (véhicule spatial sans équipage) à
5.000.000 de Km d'une planète, au lieu de 5.000 Km prévus.
Cause: une erreur de programme Fortran. Le point avait été
remplacé par une virgule (format US des nombres).
• Mariner 1 : 27 juillet 1962, la première sonde spatiale du
programme Mariner fut détruite juste après son envol.
Coût : 80 millions de dollars.
Cause: un trait d’union oublié dans un programme Fortran.
(« plus coûteux trait d’union de l’histoire », Arthur C. Clarke).
DES PETITS DÉTAILS QUI ONT FAIT LE BUG:
6 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG:
• Quelques bugs célèbres
– Tests de non-régression
– Établissement des spécifications
– Tests d’intégration
– Langages de programmation
– Interface homme-machine
– Complexité
– Informatisation inutile ?
• Pourquoi le logiciel est-il sujet aux bugs ?
7 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Lorsqu'on modifie un code, on doit effectuer deux types de
tests:
– Vérifier que la modification fait effectivement ce qu'on
attendait:
• nouvelle fonctionnalité
• correction d'un bug…
– Vérifier que la modification n'a pas mis en péril tout ce
qui marchait avant et qui doit continuer à marcher.
• Ce sont les tests de non-régression
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS DE NON RÉGRESSION (1)
8 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS DE NON RÉGRESSION (2)
• À la suite d’une modification, les tests de non-régression ne sont pas toujours effectués, car:
– on n’a pas le temps:
• La modification a été effectuée à la dernière minute
• Le marché, les clients font pression…
– on pense que la modification est locale et sans conséquence
sur le reste du système:
• Nonchalance (Je-m'en-foutisme لا مبالاة- )
• L’une des causes de bug les plus fréquentes.
9 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS DE NON RÉGRESSION (3)
• 1969: Apollo 11, serait(1) le
premier alunissage du module
lunaire (هبوط على القمر)
– Données absurdes et alarmes
logicielles intempestives
lors de l’alunissage (calcul de la trajectoire)
• (1):
https://www.youtube.com/watch?v=GWIab0y
Dj5A
10 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS DE NON RÉGRESSION (4)
• Apollo 11, premier alunissage du module lunaire (1969)
(suite)
– Déconnexion d'un module supplémentaire non
indispensable et dont le mise au point laissait à
désirer.
Les sorties de ce module (le sinus et le cosinus d ’un angle) sont lues comme 0, ce qui provoque des messages
d’alarme de mise au point, délicats à interpréter.
! : il y avait 19 secondes pour le faire.
– Modification de dernière minute
– Absence de test de non-régression
11 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS DE NON RÉGRESSION (5)
• Système de téléphone des USA (1991)
– Perturbation des communications à Los Angeles, San
Franciso, Washington, Baltimore…
– Des millions d’abonnés mécontents
– Trois (3 !) lignes de code modifiées sur plusieurs
millions, pas la peine de tester ?!
D’autant plus que la première phase de test avait duré 13 semaines et que le client n’est pas disposé à attendre une seconde fois…
– Absence de test de non-régression
– Pression du client, du marché…
12 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS DE NON RÉGRESSION (6)
• Système de contrôle des départs, British Airways,
aéroport de Londres Heathrow (2001)
– Perturbation de l’enregistrement des passagers et de la gestion des bagages
– Nombreux vols annulés ou retardés, au Royaume Uni, en
Europe et dans le monde entier ; retour à la normale
après une semaine
– Fuite de mémoire catastrophique et envahissante
– Absence de test de non-régression
– Programmation de bas niveau du système
13 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS DE NON RÉGRESSION (7)
• Premier vol d’Ariane 5 (1996)
– Auto-destruction après 40 s de
vol car le lanceur quitte sa
trajectoire nominale
– Perte du lanceur et de sa
charge utile
– Retard du programme
– Doute sur la fiabilité d'Ariane
14 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS DE NON RÉGRESSION (8)
• Premier vol d ’ Ariane 5 (1996) (suite 1)
– Une erreur de conversion
(overflow)
64 bits 16 bits
dans un module (IRS) chargé
d’estimer l’accélération et la vitesse provoque une
exception Ada (POO) pour
laquelle il n’est prévue aucun « handler »
– Le système interprète les
données de l’exception comme des données normales
(aberrantes évidemment)
15 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS DE NON RÉGRESSION (9)
• Premier vol d’Ariane 5 (1996) (suite 2)
– Le module qui a levé l ’ exception avait tourné de manière satisfaisante pendant 10 ans sur Ariane 4
• On savait qu’il n’y a pas d’overflow avec Ariane 4
• Mais la dynamique d’Ariane 5 est différente !
• Une simple simulation aurait révélé le problème…
– Comble d’ironie, le module en question était inutile à cette phase du vol !
– Enfin le système IRS était doublé, mais les deux
calculateurs exécutaient le même programme : l ’exception a donc simplement été levée deux fois !
16 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS DE NON RÉGRESSION (10)
• Premier vol d’Ariane 5 (1996) (suite 3)
– Absence de test de non-régression
– Mauvaise appréciation du rôle et des limites du
logiciel
– Gestion de projet défectueuse
17 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG:
• Quelques bugs célèbres
– Tests de non-régression
– Établissement des spécifications
– Tests d’intégration
– Langages de programmation
– Interface homme-machine
– Complexité
– Informatisation inutile ?
• Pourquoi le logiciel est-il sujet aux bugs ?
18 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: ÉTABLISSEMENT DES SPÉCIFICATIONS (1)
• Définition : une spécification est une description des
caractéristiques attendues (le quoi) d'une implémentation (le
comment):
– Claire, non ambiguës et compréhensibles.
– Cohérente.
– Attention: à cette étape on ne répond pas au comment?
• La spécification est différente selon l'étape du cycle de
vie:
– Spécification des besoins : pendant l'expression des
besoins.
– Spécification d'une architecture de système : pendant la
conception générale.
– Spécification d'un module, programme, structure de données
ou type de données : pendant la conception détaillée.
19 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: ÉTABLISSEMENT DES SPÉCIFICATIONS (1')
• Activité très délicate
– Changement de formalisme
– Prise en compte complète des scénarios d’utilisation, des effets de l’environnement, ...
The client usually does not know what questions must be
answered, and he has almost never thought of the problem
up the detail necessary for specification.
Fred Brooks, No Silver Bullet, Information Processing, 1986
20 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: ÉTABLISSEMENT DES SPÉCIFICATIONS (2)
• Sonde Mariner I, mission vers Vénus
(1962)
– Destruction commandée après 290 s
– Perte de la sonde (800 M$)
– Erreur lors de la transcription
des équations du vol qui étaient
écrites à la main : il manquait
une « barre » indiquant la moyenne
d’une grandeur ; le calculateur du lanceur a essayé de corriger une
situation qui ne nécessitait
aucune correction
– Passage délicat d’un formalisme à un autre
21 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: ÉTABLISSEMENT DES SPÉCIFICATIONS (3)
• Boeing 767 d’UA en approche à Denver (1983)
– Arrêt des deux réacteurs par suite de givrage
– 14 minutes de vol plané
– Pour diminuer la consommation de carburant, le système
ralentissait les moteurs au maximum ;
l’avion traversait alors une tempête et il y faisait très froid givrage
– Oubli des lois physiques lors des spécifications
• Pas de prise en compte de la température extérieure
22 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: ÉTABLISSEMENT DES SPÉCIFICATIONS (4)
• Missile MIM-104, guerre du Golfe (1991)
– Défaut d’interception d’un missile Scud irakien
– Une erreur d’arrondi dans le calcul du temps s’accumulait, faussant la précision de l’interception
• le temps était stocké en 1/10 s
• pour obtenir la durée, on devait multiplier par 0.1
• 0.1 ne peut être stocké exactement
(calcul en virgule fixe sur 24 bits)
Erreur d’arrondi qui au bout de 100 heures est de 0.34 s
• à la vitesse du Scud (1676 m/s), cela représente plus de
500 m
23 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: ÉTABLISSEMENT DES SPÉCIFICATIONS (5)
• Missile MIM-104, guerre du Golfe (1991) (suite)
– Spécification incomplète et fonctionnement hors normes
• En temps normal, le système devait être rebooté
tous les jours, mais ce mode de fonctionnement
n’était qu’implicite dans le cahier des charges.
• Lors de l’accident, il tournait depuis 5 jours d’affilée.
• Le bug était connu depuis le début de la guerre et
déjà corrigé chez le constructeur. Mais considérée
non critique, la mise à jour n’a été déployée que le lendemain !
24 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: ÉTABLISSEMENT DES SPÉCIFICATIONS (6)
• Observation de la couche d’ozone (1979-1980)
– Les satellites de la NASA détectent des taux très bas
d’ozone dans certaines régions et le logiciel considère qu’il s’agit d’erreurs
– La reconnaissance de la réalité de ces taux ne sera
affirmée qu'en 1986, suite à des études britanniques
– Défaut de spécification face à un phénomène inconnu
25 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG:
• Quelques bugs célèbres
– Tests de non-régression
– Établissement des spécifications
– Tests d’intégration – Langages de programmation
– Interface homme-machine
– Complexité
– Informatisation inutile ?
• Pourquoi le logiciel est-il sujet aux bugs ?
26 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS D'INTÉGRATION (1)
• Précédés des tests unitaires et suivis par les tests de
validation.
• Tests unitaires
– Vérifier qu'une entité individuelle (classe, module,
composant) se comporte correctement
– Basé sur le texte et la spécification
• Tests d'intégration
– Vérifier que l'assemblage d'entités (classes, modules,
composants) se comporte correctement
– Test des interactions des modules
– Phase essentielle avant la recette du système
• Tests de validation
– Vérification des fonctionnalités décrites dans les
spécifications de plus haut niveau.
• Tests de non-régression (déjà mentionnés)
– Vérifier qu'une modification n'a aucun effet négatif sur le
fonctionnement global du système.
27 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS D'INTÉGRATION (2)
• Mars Climate Orbiter (1999)
– Mise en orbite ratée ;
écrasement sur Mars
– Échec de la mission (125 M$)
– La poussée de la fusée était
évaluée en unités de mesure
anglosaxonnes dans un module
et transmise à un autre module
qui attendait des unités
métriques !
– Mauvaise communication entre
deux contractants (Lockheed et
Jet Propulsion Laboratory)
– Tests d’intégration défaillants
– Management défaillant
28 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: TESTS D'INTÉGRATION (3)
• 1999: Mars Polar Lander (Mars Surveyor'98)
– Écrasement sur Mars au lieu d’un atterrissage en douceur
– Échec de la mission (194 M$)
– Les vibrations entraînées par
le déploiement des pieds de la sonde
furent mal interprétées par le logiciel
de bord, qui considéra que ces vibrations étaient le signe
d'une arrivée sur le sol martien. Les moteurs destinés à
freiner la descente de la sonde furent coupés
prématurément, alors que la sonde était encore à
40 mètres de la surface (Wikipedia: Mars Polar Lander).
– Mauvaise communication entre deux modules
– Langages de programmation inadaptés (unités et quantités
physiques)
– Tests d’intégration défaillants – Management défaillant
29 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG:
• Quelques bugs célèbres
– Tests de non-régression
– Établissement des spécifications
– Tests d’intégration
– Langages de programmation
– Interface homme-machine
– Complexité
– Informatisation inutile ?
• Pourquoi le logiciel est-il sujet aux bugs ?
30 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: LANGAGES DE PROGRAMMATION (1)
• Réseau de téléphone longue distance d’AT&T (1990)
– 9 heures d’interruption de service
– Mauvais placement d'une instruction break en C
– La syntaxe concrète importe !
– Défaut de test
– La duplication des commutateurs n'a encore servi à
rien, puisque les secondaires exécutaient le même
programme que les primaires
31 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: LANGAGES DE PROGRAMMATION (2)
• Sonde Mariner I, mission vers Vénus (1962)
– Le bug suivant, trouvé dans le code Fortran de Mariner I, ne
semble pas avoir eu de conséquence
DO5I = 1.5
C’est une affectation ! L’instruction correcte (une boucle pour I variant de 1 à 5) aurait du être
DO5I = 1,5
ou plutôt
DO 5 I = 1, 5
32 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: LANGAGES DE PROGRAMMATION (3)
• Du danger de certaines syntaxes concrètes : l’exemple de C
– Le terrible break
– Le classique
if (x = 0) … à la place de if (x == 0) …
– Le moins classique, mais piégeant
t[i, j] = …; à la place de t[i][j] = …;
– Le redoutable
if (x > 1,5) … à la place de if (x > 1.5) …
– etc.
33 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: LANGAGES DE PROGRAMMATION (4)
• « Buffer Overflow » (1998)
– Envoi de longs courriers provoquant le débordement d’un buffer non protégé
– Une des voies d’attaques des systèmes sur Internet
– Modèle de mémoire linéaire et sans contrôle des langages
comme C
– Sérieux problème de sécurité
34 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: INTERFACE HOMME MACHINE (1)
• Quelques propriétés souhaitables d'une bonne IHM:
– Présenter à l'opérateur l'information de manière claire
et lisible (Non Ambigüe)
– Permettre les actions de l'opérateur de manière simple
et non confuse (Non Ambigüe)
– Ne pas faire confiance à l'opérateur mais vérifier la
pertinence de ses actions et ses entrées
35 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: INTERFACE HOMME MACHINE (2)
• USS Vincennes, Golfe Persique (1988)
– La frégate USS Vincennes abat un
Airbus civil d’Iran Air en le prenant pour un avion de combat hostile
– 290 morts
– L’interface opérateur des radars Aegis de la frégate était complexe
et confuse.
Les opérateurs ont cru que l’avion était en descente vers le navire, alors qu’il montait.
– Interface opérateur trop complexe
– Avis des utilisateurs négligé ?
– Entraînement et formation ?
– Stress des opérateurs ?
• La frégate était engagée avec des unités de surface
hostiles…
• Ce n’est pas une excuse recevable pour un système militaire !
36 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: COMPLEXITÉ (1)
• De nombreuses échecs informatiques sont simplement dus à la
complexité du système, en général associée à des facteurs
comme:
– Sécurité: Trop de suspicions
– Incompétence (totale ou partielle),
– Arrogance: JE SUIS … (c'est aux autres de s'adapter)
– Mauvaise gestion de projet
– Application sans référence antérieure
– Volonté « aveugle » : concurrence, spécifications
démentielles…
– …
37 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: COMPLEXITÉ (2)
• Informatisation du « dispatching » des ambulances à
Londres (1992)
– Cartes informatisées, gestion des appels, envoi des
ambulances.
– Pertes d’appels, attentes lors des appels (jusqu’à 30 min), retards d’ambulance (jusqu’à 11 heures !), plusieurs ambulances envoyées au même endroit, fausses alarmes…
– Système arrêté au bout de 36 heures.
• http://erichmusick.com/writings/technology/1992-london-ambulance-cad-
failure.html
• https://en.wikipedia.org/wiki/London_Ambulance_Service
38 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: COMPLEXITÉ (3)
• Informatisation du « dispatching » des ambulances à
Londres (1992) (suite)
– Gestion de projet discutable
• Tests insuffisants et irréalistes
• Hypothèses irréalistes
– information quasi-parfaite de la part des
appelants
– information parfaite du système (la carte de
Londres, la liste des noms des rues étaient
incomplets)
– Interface homme-machine médiocre
• Pas de possibilité de tracer les appels reçus,
• Pas de possibilité de vérifier que la réponse aux
appels avait été adéquate
39 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: COMPLEXITÉ (4)
• Système de manipulation
automatique des bagages de
l’aéroport de Denver (1993-1995)
– Système « Gigantesque »
• 4000 véhicules (telecars),
3 terminaux, plus de 30 km
de circuit, 300 ordinateurs
• 193 M$ (12 % du coût total)
• Toutes les compagnies
devaient être desservies
40 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: COMPLEXITÉ (5)
• Système de manipulation
automatique des bagages de
l’aéroport de Denver (1993-1995) (suite 1)
– Chaos total lors des tests
– Bagages détruits
– Crashes, collisions,
détérioration des rails…
– Blocage des telecars par les
bagages qu’ils détruisaient…
41 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: COMPLEXITÉ (6)
• Système de manipulation automatique des bagages de
l’aéroport de Denver (1993-1995) (suite 2) – Retard d’ouverture de l’aéroport de plus de 16 mois – Le système (bien réduit) n’est utilisé que par une seule
compagnie (UA), et encore uniquement pour les vols en
partance. Pour les autres, on a du se rabattre sur un
système plus classique
– À cause du retard et des solutions alternatives nécessaires,
le coût total de l’aéroport est passé de 1,7 B$ à 4,5 B$ • Dette de 1 M$ par jour pour Denver
• Denver est l’aéroport des USA où les taxes sont les plus élevées !
– Taille et complexité du projet, pas de référence préalable
• https://en.wikipedia.org/wiki/Denver_International_Airport#Automated_baggag
e_system
42 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: INFORMATISATION UTILE ?! (1)
• Certains échecs informatiques sont d’autant plus amers que l’informatisation n’était pas vraiment indispensable:
– Effet de mode - concurrence
– Mauvaise appréciation des systèmes concurrents
– Engouement pour l’informatique et ses « retombées » positives.
• Ce syndrome s’accompagne souvent d’un des aspects suivants
– Complexité, système « Gigantesque »
– Mauvaise gestion
– Application sans référence antérieure
43 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: INFORMATISATION UTILE ?! (2)
• Informatisation des commandes de « ferries », état de
Washington (1990)
– Remplacement des commandes hydrauliques par des
commandes informatisées
– Embarcadères défoncés, mise en route ou passage en
marche arrière intempestifs…
– Retour au « vieux » système hydraulique
– Gestion de projet
– Pas de référence préalable
– Inutile ou prématuré
44 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
DES PETITS DÉTAILS QUI ONT FAIT LE BUG: INFORMATISATION UTILE ?! (3)
• Automatisation des usines de General Motors (1980-
1985)
– Informatisation du transport des pièces (50 chariots
téléguidés) et des 290 robots de soudure et de
peinture
– Manque de fiabilité générale
• Les robots se démantibulent entre eux, abîment les
voitures, projettent de la peinture…
• Le système doit très souvent être arrêté pour
identifier et corriger les bugs
– Gestion de projet
– Informatisation inutile ou prématurée
– Mauvaise estimation de l'apport de l'informatisation :
le but était ici de concurrencer les méthodes
japonaises !
45 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Autour du Bug: (a very small insect [En])
– Défaut de conception d'un programme informatique à
l'origine d'un dysfonctionnement. (Wikipedia/Fr)
– A software bug is an error, flaw, failure, or fault in a
computer program or system that causes it to produce an
incorrect or unexpected result, or to behave in
unintended ways (Wikipedia/En)
Un bogue logiciel est une erreur, défaut, échec ou faute
dans un programme ou un système informatique qui pousse
à la production d'un résultat incorrect ou inattendu, ou
un comportement involontaire.
– Les bugs surviennent quand le logiciel ne correspond pas
au besoin.
• Un bug = non-respect de la spécification du système,
c’est-à-dire de la définition de ses fonctionnalités, de
ce que le système est censé faire.
• Un programme bogué = programme dont la mise en œuvre ne
vérifie pas la spécification
POURQUOI LE LOGICIEL EST IL SUJET AUX BUGS ?
46 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Le logiciel ignore la continuité naturelle des phénomènes.
• Les ingénieurs logiciels ont souvent peu de connaissances
sur les contraintes de la réalité informatisée.
• Modifications permanentes du cahier des charges, des
spécifications…
• Extensions, nouvelles fonctionnalités
POURQUOI LE LOGICIEL EST IL SUJET AUX BUGS ?
47 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• En résumé:
– Taille et complexité des logiciels (IHM mal soignée),
– Taille des équipes de conception/développement,
– Manque de méthodes de conception,
– Négligence de la phase d'analyse des besoins du client,
– Tests non effectués (négligence | pression du client)
– Informatisation inutile;
POURQUOI LE LOGICIEL EST IL SUJET AUX BUGS ?
48 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Respect des engagements :
– 30% des projets informatiques sont annulés avant la mise en
production (Aberdeen).
– En 1995, aux USA, on estime à 91 billions de dollars, la
somme dépensée pour des projets arrêtés avant la fin.
– 90% des projets informatiques sortent en retard (Aberdeen).
– 50% des projets informatiques ne répondent pas au cahier des
charges Business (Gartner).
– 50% des projets informatiques dépassent le budget prévu
(Gartner). Ce surplus du coût se répartit ainsi :
maintenance corrective : 20 %
maintenance adaptative : 25 %
maintenance évolutive et perfective : 55 %
• Les dépenses en informatique (TIC) sont importantes.
Ex: Elles représentent aux USA 12,5% du PNB (1990) et 5% du
PIB en 2000.
QUELQUES CHIFFRES - BILAN
49 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Tous ces constats font que les années 70 voient naître une
crise de l'industrie du logiciel dont les principales raisons
sont :
– le non-respect (augmentation) des coûts
– le non-respect (augmentation) des délais
– l’inadéquation avec les besoins des utilisateurs
– le non-respect des spécifications
– la non-fiabilité
– les difficultés d'évolution
• une conception et un développement difficiles :
– complexité croissante des logiciels (la productivité ↘ lorsque la complexité du logiciel ↗ )
– trop d’interrelations entre composants logiciels
– trop de modifications (évolutions)
– tests souvent insuffisants
QUELQUES CHIFFRES - BILAN
50 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Communication difficile :
– jargon utilisateur Vs jargon informatique
– évolution de la manière de voir un problème
– réflexion utilisateur pas assez mature
– marché, législation et besoin en perpétuelle évolution
– addition successive d’imprécision dans la communication entre
les individus d’une équipe (la complexité ↗ avec le nombre d’intervenants)
• Naissance du Génie Logiciel pour répondre aux 2 problèmes :
– Non fiabilité du logiciel,
– Difficulté de réalisation de logiciel dans les délais prévus
et vérifiant le cahier de charge.
QUELQUES CHIFFRES - BILAN
51 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• ORIGINES:
Terme (Software Engineering) introduit en 1968
– Conférence de l’OTAN à Garmish Parten Kirchen
– La « crise du logiciel » (déjà !)
• BUTS:
– Satisfaction aux besoins du client.
– Augmenter la qualité du logiciel
• Performance, fiabilité, sûreté
• Évolutivité, maintenabilité
– Augmenter la productivité des équipes de développements
• Taille des équipes
• Durée de développement
– Livraison dans le délai et le budget prévus à l’avance,
– Optimisation des coûts de développement du logiciel.
GÉNIE LOGICIEL
52 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• DÉFINITIONS:
– D’après la Norme IEEE 610.12 : Le Génie Logiciel est
l’application d’une approche systématique, disciplinée et
quantifiable au développement, à l’exploitation et à la
maintenance du logiciel.
(càd, l’application de l’ingénierie au logiciel)
– D’après MC. Gaudel : Le Génie Logiciel est l’art de
spécifier, de concevoir, de réaliser et de faire évoluer,
avec des moyens et dans des délais raisonnables, des
programmes, des documentations et des procédures de
qualité en vue d’utiliser un système informatique pour
résoudre certains problèmes.
– Le Génie Logiciel est l’art et la science de concevoir et
de construire, avec économie et élégance, des
applications, des objets, des frameworks et d’autres
systèmes informatiques, qui soient corrects, robustes,
extensibles, réutilisable.
GÉNIE LOGICIEL
53 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• DÉFINITIONS (SUITE):
– Le Génie Logiciel est un ensemble de moyens (techniques et
méthodologiques) permettant la construction de systèmes
informatiques répondant à des critères de qualité
préalablement définis.
– Méthodologie de construction en équipe d’un logiciel
complexe et à multiples versions
– Le génie logiciel est la construction à plusieurs
personnes d’un logiciel à multiples versions.
– Ensemble de méthodologies, méthodes, techniques et outils
pour produire, utiliser et maintenir du logiciel de
qualité industrielle
Attention:
Programmation Génie Logiciel
• Programmation est une activité personnelle.
• Génie logiciel est une activité d’équipe.
GÉNIE LOGICIEL
54 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• PASSAGE DE LA PROGRAMMATION "IN THE SMALL"
GÉNIE LOGICIEL
• Algorithmique, structures de données, langages de programmation.
• Small program
• Small groups
• Short time periods (quick to code)
• short-lived programmatic behavior
• Less formal practices
• Rapid application development
is more important than stability
or correctness.
55 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• PASSAGE DE LA PROGRAMMATION "IN THE SMALL" À LA PROGRAMMATION "IN THE LARGE"
GÉNIE LOGICIEL
• Transformation d’un cahier de charge vague en spécifications
précises,
• Capacité de communication avec l’utilisateur en terme
d’application (ouverture vers d’autres domaines),
• Maîtrise des différents niveaux d’abstraction,
• Capacité de modélisation,
• Capacité de communication inter-personnelle,
• Capacité d’organisation et de planification.
• larger groups || smaller groups over longer time periods.(W)
56 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• PASSAGE DE LA PROGRAMMATION "IN THE SMALL" À LA PROGRAMMATION "IN THE LARGE"
GÉNIE LOGICIEL
57 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• QUELQUES CRITÈRES:
GÉNIE LOGICIEL
• Logiciel de qualité industrielle
– Longue durée de vie
• Gestion des versions, maintenance.
– Longue durée de développement, grandes équipes
• Changement des spécifications.
• « Time To Market » (TTM): Temps nécessaire depuis la
conception d'un produit jusqu'à sa mise en vente sur
le marché.
– Performances, fiabilité, sûreté élevées.
– Interface utilisateur adéquate.
– Prix « approprié ». (avec ou sans maintenance)
58 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: PARFAIT ?!
• Pas autant d'exigences dans les autres domaines technologiques.
Ex. : voiture, circuits, constructions …
• Donc estimation de la qualité:
Ex. Domaine du transport:
Taux de défaillance "acceptable" :
10-7 pannes/heures (avion)
10-9 pannes/heures (train)
59 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Approche classique de l’ingénieur
– Définition claire du problème à résoudre,
– Développement d’outils et de techniques pour le résoudre
GÉNIE LOGICIEL
60 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: NATURE DES COÛTS
• Frais de personnel très élevés
– Hauts salaires
– Frais de formation
• Coûts de développement variables selon les applications
• Pour les systèmes à longue durée de vie, coûts de
maintenance élevés
61 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: NATURE DES COÛTS
Type de système
Pourcentage des coûts par phase
Analyse et
conception Implémentation
Test et
Intégration
Régulation et contrôle 46 20 34
Aérospatiale 34 20 46
Système
d’exploitation
33 17 50
Calcul scientifique 44 26 30
Gestion 44 28 28
• D’après Boehm
• Règle: Un logiciel coûte plus à maintenir qu’à développer.
62 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: FACTEURS DE RÉUSSITE
• Comme toute discipline d’ingénierie, le génie logiciel n’est pas purement technique:
– Aspect humains
• Sélection, constitution, et gestion des équipes
• Formation des personnels
• Relation avec les clients prescripteurs
– Aspects financiers
• Estimation des coûts
• Suivi de projet
• Gestion budgétaire
63 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: FACTEURS DE RÉUSSITE
• Gestion rigoureuse du processus de développement
– Aspects techniques, humains, administratifs
– Définition de « bonnes pratiques » (best practices)
• Techniques de vérification et de validation (V&V)
– Vérification : « Are we building the product right ? »
– Validation : « Are we building the right product ? »
– Prise en compte très tôt des impératifs de V&V
• Utilisation de méthodes et d’outils dans toutes les phases
64 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: FACTEURS DE RÉUSSITE
• Séparation des problèmes
– Dans le temps (cycle de vie), des qualités (ex. correction puis
efficacité), des vues (ex. flots de données avant flot de
contrôle), en partie (modularité) …
• Modularité
– Composition en sous-systèmes plus simples (modules)
– Forte cohésion interne du module et un faible couplage entre les
modules.
• Abstraction
– Ne considérer que les aspects jugés importants d'un système en
ignorants les autres détails.
• Anticipation du changement: Prévision des évolutions inévitables.
• Généralisation
– Avantage de remplacer un problème spécifique par un problème plus
général dont la solution pourra être réutilisée.
• Construction incrémentale
65 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: FACTEURS DE RÉUSSITE
• Quelques pistes
– Meilleurs langages
– Meilleur personnel
– Meilleurs outils
– Réutilisation
– Ré-ingénierie: revue, màj, réorganisation
– voire retro-ingénierie (Reverse engineering – back
engineering [En]): étude, compréhension et détermination de
l'existant pour une réutilisation ou adaptation
– Modélisation, transformation de modèle
66 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: FACTEURS DE RÉUSSITE
• L’importance de la modélisation
– Modéliser est habituel dans les disciplines de l’ingénierie
Le logiciel a longtemps échappé à cela…
– L ’ apparition des techniques structurées ou de modélisation des données (années 1980), puis des méthodes orientées-
objets (années 1990), enfin d ’UML (fin 1990) ont rendu à la modélisation sa juste place
– L’approche MDA (Model-Driven Architecture) de l’OMG tente de placer la modélisation au centre du processus
– C’est loin d’être encore une pratique courante partout !
• Quand on modélise, on ne code pas.
• On pense toujours que la seule vérité est dans le code !
67 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: QUALITÉ !
• Normes générales et internationales de qualité
– Familles de normes (9000 à 9004) selon l’activité de l’entreprise (ou d’un de ses départements)
– Procédure de certification et d’accréditation
– Applicable aussi bien à la fabrication des boulons, des
automobiles, ou même à la formation des ingénieurs !
– De nature très bureaucratique !
• Qualité externe vs Qualité interne
- Externe : vision client
- Interne : vision développeur
68 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: QUALITÉ !
• Il est difficile d ’ évaluer directement la qualité du
logiciel lui-même
– Utilisation de métriques ?
• Au niveau analyse, conception, architecture, code ?
• Nombreuses métriques différentes, nombreux débats…
• Il semble plus atteignable d ’ évaluer la qualité du
processus de développement de logiciel
– Normes ISO 9000
– Capability Maturity Model Integration (CMMI)
– La qualité (administrative, bureaucratique…) du
processus n'est pas une garantie absolue de la qualité
du produit.
69 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
GÉNIE LOGICIEL: CAPABILITY MATURITY MODEL INTEGRATION
• Modèle de référence, un ensemble structuré de bonnes
pratiques, destiné à appréhender, évaluer et améliorer les
activités des entreprises d'ingénierie. (Wikipedia)
• Modèle établi par le Software Engineering Institute,
université de Carnegie Mellon, Pittsburg (SEI-CMI)
– Première publication en 1986
• Spécifique au logiciel (CMM)
– Révisé en 2002
• Étendu à l’ingénierie des systèmes (CMMI)
• Analyse de la maturité des entreprises (ou d ’ un de leurs départements) par rapport à l’organisation de leur processus de développement de logiciel
70 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Invisibilité du logiciel :
– Un logiciel ne peut être testé et observé qu’à la fin de son
développement
– Donc besoin de méthodes de spécification et de modélisation.
– Présentation des différents schéma au futurs réalisateurs et
utilisateurs pour validation.
• Flexibilité du logiciel :
– Les modifications sont délicates à concevoir, avec des
conséquences difficiles à anticiper.
– Toute modification d’une partie d’un programme peut affecter
cette partie et d’autres parties du programme.
PARTICULARITÉ DU LOGICIEL:
71 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• noyau Linux : 3,7 M instructions
• portail Yahoo : 11 M instructions
• W95 : 10 M instructions
• téléphone mobile : 150 K instructions
• automobile : 1 M instructions
• central téléphonique : 1 M instructions
• montre: 2 K instructions
DES LOGICIELS PARTOUT
72 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Validité - correspond aux spécifications définies par le cahier
des charges
• Fiabilité (robustesse) - gestion des conditions ”anormales”
• Facilité d’utilisation (ergonomie)
• Extensibilité
• Réutilisabilité (en tout ou en partie)
• Compatibilité
• Efficacité (Performance) - utilisation optimale des ressources
matérielles
• Portabilité - transfert sous différents environnement matériels
et logiciels
• Intégrité - aptitude du logiciel à protéger son code et ses
données contre des accés non autorisés
• Vérifiabilité - facilité de préparation des procédures de test
EN RÉSUMÉ, LES QUALITÉS D'UN LOGICIEL (À NE PAS CONFONDRE AVEC LES NORMES QUALITÉ):
73 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
EN RÉSUMÉ, LES QUALITÉS D'UN LOGICIEL:
74 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Comme toute fabrication, un logiciel est produit en
suivant un certain processus.
• Particularité :
– pas de fabrication en série (par simple copie)
– étapes = suite de raffinements successifs
– une nature itérative
– l'invisibilité
PROCESSUS DE DÉVELOPPEMENT DU LOGICIEL
75 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Une étape se termine par la production de documents qui
sont vérifiés et validés avant de passer à l'étape
suivante.
Permet le contrôle de l'avancement des activités et la
validation des résultats intermédiaires.
• Une étape peut faire intervenir plusieurs activités
Ex. Dans l'étape de conception on peut trouver
• spécification globale,
• Maquettage,
• Validation.
• Une activité peut se dérouler pendant plusieurs étapes
Ex. l'activité de documentation : pendant tout le
processus.
ÉTAPE ET ACTIVITÉ
76 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
1. Analyse des besoins
• Objectifs :
– Étude du domaine d'application;
– Étude de l'état actuel de l'environnement du futur
système, le rôle du système, les ressources disponibles
et requises ….
• Données fournies par des spécialistes du domaine
d'application et non des informaticiens.
– Entretiens, questionnaires, observations …
• Résultat un ensemble de documents descriptifs. Un manuel
d'utilisation préliminaire peut aussi être fourni.
• Remarques :
– Activité essentielle au bon démarrage du processus.
– Menée en liaison avec les études de faisabilité et la
planification.
– Se poursuit durant tout le processus de développement.
LES ACTIVITÉS (1)
77 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
2. Spécification globale
• Objectif : Première description du future système
• Données :
– Résultat de l'activité d'analyse des besoins
– Considération de technique et de faisabilité
informatique
• Résultat : Description de ce que doit faire le logiciel
(le quoi mais pas encore le comment). Une 1ère version
du manuel de référence peut aussi être fournie ainsi
que des compléments au manuel d'utilisation.
• Remarques :
– Liée à l'analyse des besoins
– Corrélée avec l'activité de validation
– Pas de choix d'implémentation prématurés
LES ACTIVITÉS (2)
78 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
3. Conception architectural et détaillée
• Objectif : Enrichissement de la description du logiciel
avec des détails d’implémentation.
• Se déroule en 2 étapes :
– Conception architecturale : décomposition du logiciel en
composants plus simples. Précision des interfaces et des
fonctions de chaque module.
Résultat :
- Description architecturale du logiciel
- Spécifications des différents composants.
– Conception détaillée : algorithmes et représentation des
données pour chaque module.
• Remarques :
– Une conception possible démontre la faisabilité du logiciel.
– La conception peut commencer pendant la spécification et
peut la remettre en cause.
– Frontière floue entre spécification et conception : il
n’est pas raisonnable de spécifier un système sans prendre
en compte les considérations de faisabilité.
LES ACTIVITÉS (3)
79 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
4. Programmation
• Objectif : ensemble de programmes ou composants de
programmes.
• Données : résultat de la conception détaillée.
5. Gestion de configuration et intégration
• Gestion de configuration :
• Permettre la gestion des composants du logiciel
• Maîtriser les mises à jour tout au long du processus
de développement
• Activité informatisée en utilisant les EDI
[Environnement de Développement Intégré] (IDE [En])
• Intégration :
• Assembler tout ou une partie des composants d’un
logiciel pour obtenir un système exécutable.
• Utilise la gestion de configuration pour assembler des
versions cohérentes de chaque composant.
LES ACTIVITÉS (4)
80 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
6. Validation et vérification
• Validation : "are we building the right product?"
Correction externe fonction des besoins
- Revues et inspections de spécifications ou de manuels
et du prototypage rapide
- L'analyse des besoins et la spécification globale sont
liées à la validation
LES ACTIVITÉS (5)
81 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Vérification : "are we building the product right ?"
Correction interne
- Inspections de spécifications ou de programmes, preuve et
test.
• Preuve : vérification qu'une spécification détaillée ou
qu'un programme satisfait la spécification de départ.
• Test :
– Recherche des erreur dans une spécification détaillée
ou un programme.
Statique : examen ou analyse du texte
Dynamique : exécution sur un sous-ensemble fini des
données possible
– 3 types : unitaire, d'intégration et système.
- La conception et la programmation impliquent la vérification
LES ACTIVITÉS (6)
82 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
7. Maquettage (prototypage rapide)
– Dans le cas où les besoins et la caractéristiques sont
imprécis.
• Programme = ébauche du future système
• Pas de performances, peu de fonctionnalités
• Soumis à des scénarios avec les futurs utilisateurs =
maquette exploratoire
– Pendant une étape de conception où plusieurs choix sont
possibles
• Maquette expérimentale.
LES ACTIVITÉS (7)
83 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• La 1ère tentative : séparation de l'analyse et de
l'implémentation
LES MODÈLES
Analyse
Implémentation
84 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
– Ensemble d'étapes
– Chaque étape produit des
documents ou logiciels
– Revue des résultats d'une étape
avant de passer à l'étape
suivante
– Remise en cause de l'étape
précédente rigidité et
linéarité
– Validation-vérification dans
chaque étape
Faisabilité
Analyse besoins
planification
Conception du
produit
Conception
détaillée
Le codage
Intégration
Installation
Exploitation et
maintenance
MODÈLE EN CASCADE (CHUTE D'EAU)
85 COURS CONCEPTION ORIENTÉE OBJET – UML2
EX.2. DÉVELOPPEMENT EN CASCADE (WATERFALL)
Analyse des
besoins
Spécification
Conception
Codage
Test
Validation
Recette
86 COURS CONCEPTION ORIENTÉE OBJET – UML2
Recette: vérification de conformité d'un produit.
NOTIONS SUR LE GÉNIE LOGICIEL
• Inconvénient :
– Pas de validation
intermédiaire
– Pas d’adaptabilité
• Conséquences :
– Erreur d’analyse et
évolution coûteuse
(effet tunnel)
MODÈLE EN CASCADE (CHUTE D'EAU)
87 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Aucune validation intermédiaire
– Impossibilité de suivre le déroulement du projet, donc de
planifier un travail en équipe
– Augmentation des risques car la validation est tardive :
erreur d’analyse ou de conception très coûteuse
• Solution limitée aux petits problèmes
– Risques bien délimités dès le début du projet
– Projet court avec peu de participants
MODÈLE EN CASCADE (CHUTE D'EAU)
88 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Variante du waterfall
• Distingue deux branches
– Production de code
– Tests
– Place en regard les
activités liées
• Les 1ères étapes préparent
les dernières
Ex. à la fin de la conception
architecturale le protocole
d'intégration et les jeux de
test doivent être
complètement décrit
Analyse besoins
Faisabilité
Spécification
Conception
architectural
Conception
détaillée
Programmation
Installation et
test système
Test
d'acceptation
Intégration et
test d'intégration
Test unitaire
MODÈLE EN V:
89 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Validations intermédiaires
– Bon suivi de projet:
points de mesure concrets
de l’avancement du
travail avec étapes clés
– Favorise la décomposition
fonctionnelle de
l’activité
– Limitations des risques
en cascade par validation
de chaque étape
• Modèle éprouvé très utilisé
pour de grands projets
MODÈLE EN V : AVANTAGES
90 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Un modèle toujours séquentiel
– Prédominance de la
documentation sur
l’intégration : validation
tardive du système global
– Les validations intermédiaires
n’empêchent pas la
transmission des insuffisances
– Peu d’adaptabilité
– Maintenance non intégrée:
logiciel jetable
• Adapté aux problèmes bien connu
• Idéal quand les besoins sont
bien connus, quand l’analyse et
la conception sont claires
MODÈLE EN V : DÉSAVANTAGES
91 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• le processus en cascade est souvent apprécié des managers
(Facile à planifier)
• Mais il est moins facile de respecter le plan !
• L ’ utilisation du processus en cascade est (maintenant)
reconnu comme une des sources majeures des échecs de
projets logiciels: 13% à 20% de réussite (Étude de J.
Johnson 2002)
MODÈLE EN CASCADE: BILAN
toujours
7%
souvent
13%
parfois
16%
rarement
19%
jamais
45%
92 COURS CONCEPTION ORIENTÉE OBJET – UML2
LE MODÈLE EN SPIRALE
Détermination
des objectifs,
des alternatives,
des contraintes
Analyse de risque
Analyse de risque
Analyse de risque
Analyse
de risque
Prototype 1
Prototype 2
Prototype 3
Prototype
opérationnel
Simulation, modélisation, benchmark Concepts
d'opération
Plan
général du
projet
Validation des
besoins
Plan de
développement
Validation de la conception
Vérification
Plan
d'intégration et
de test
Conception
détaillée
Programmation
et test unitaire Intégration
et test Test
système Mise
en
œuvre
2 1
3 4
93 COURS CONCEPTION ORIENTÉE OBJET – UML2
LE MODÈLE EN SPIRALE : EXPLICATION
• Plus général que les autres modèles
• Accent mis sur l’activité d’analyse de risque
• Chaque cycle se déroule en 4 phase (les quadrants) :
1. Détermination, à partir des cycles précédents, des
objectifs du cycle, des alternatives pour leur
réalisation et des contraintes.
Dans le cas su premier cycle c’est une analyse
préliminaire des besoins.
2. Analyse des risques, évaluation des alternatives et
maquettage
3. Développement et vérification de la solution retenu
4. Revue des résultats et planification du cycle suivant.
• Mise en œuvre nécessite des compétences et un effort
important.
94 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Prototypage
– Idée : fournir le plus rapidement possible un prototype
exécutable permettant une validation concrète et non sur
document
– Progression du projet par incrémentations successives de
versions du prototype : itérations
– Certains prototypes peuvent être montrés au client. Par
ailleurs, une maquette peut être réalisable préalablement
au premier prototype
– La validation par prototype ne justifie pas l’absence de
recours à la documentation !
MODÈLE EN SPIRALE:
95 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Rectification au plus tôt des erreurs détectées lors des
phases précédentes
• Adaptabilité via une meilleure gestion des exigences et la
prise en compte des évolutions
MODÈLE EN SPIRALE: AVANATAGES
96 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
• Validation concrète et non sur documents
• Limitation du risque à chaque itération
• Client partenaire : retour rapide sur ses attentes
• Progressions : pas d’explosion des besoins à l’approche de
la livraison : pas de « n’importe quoi pourvu que ça
marche »
• Flexibilité :
– Modification des spécifications = nouvelle itération
– Maintenance = forme d’itération
• Planification renforcée
MODÈLE EN SPIRALE: AVANTAGES
MODÈLE EN SPIRALE: DÉSAVANTAGES
• Processus adapté à la modélisation objet
• Modèle objet : se prête parfaitement à une démarche
incrémentale
• Le cycle en spirale a cependant une portée générale
97 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
MODÈLE EN SPIRALE: RÉSUMÉ
• Processus itératif
Orienté prototypage (Livraison d’un exécutable permettant
une validation concrète )
• Place importante
– des tests
– de l’analyse de risque
• Facilite
– la réutilisation
– l’intégration du client
– l’évolution des spécifications
• À la base de tous les processus « agiles »
98 COURS CONCEPTION ORIENTÉE OBJET – UML2
LE MODÈLE PAR INCRÉMENTS
temps
Conception
Architecturale
Conception
détaillée
Programmation
Test
Conception
Architecturale
Conception
détaillée
Programmation
…
Conception
Architecturale
Conception …
détaillée
Incrément 1
Incrément 2
Incrément 3
• Modèles déjà vus:
• Conception architecturale: décomposition en composant
• Composants développés indépendamment les uns des autres
• Modèles par incréments: un seul sous-ensemble des composants
est développé à la fois:
• Logiciel (incrément) noyau est développé, puis
• des incréments sont développés et intégrés.
99 COURS CONCEPTION ORIENTÉE OBJET – UML2
LE MODÈLE PAR INCRÉMENTS (AVANTAGES ET INCONVÉNIENTS)
• Avantages
– Chaque développement est moins complexe
– Les intégration sont progressives
– Possibilité de livraison et de mise en service après
chaque intégration
– Une meilleure estimation dans le temps des effectifs
et de l'effort de développement
– Modèle utilisé dans les grands projets
• Inconvénients
– Risque de remise en cause du noyau (1er incrément) ou
des incréments précédents.
– Risque d'incapacité d'intégrer un incrément
Spécification globale, au début du projet, du noyau et
des autres incréments, ainsi que de leurs interactions
Des incréments le plus indépendants possibles.
100 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
MÉTHODES:
• Pour gérer un cycle de vie, il est nécessaire
d’utiliser :
Des méthodes
Des outils
• La méthode : règles et pratiques mis en oeuvre par le
chef de projet pour conduire son projet.
• Longtemps dominant, Merise, avec son approche
systémique (par la structure) et ses validations en
cascade, est aujourd’hui critiquée pour sa rigidité,
son manque d’adaptation et son effet tunnel
• On a vu alors apparaître une tendance à rapprocher les
utilisateurs des développeurs, avec des cycles
d’itérations plus courts…
Extrait du magazine L’informaticien n° 009
• Émergence des méthodes agiles
101 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
MÉTHODES AGILES: ORIGINES
• Instabilité de l'environnement technologique
• Le client est souvent dans l'incapacité de définir ses besoins
de manière exhaustive dès le début du projet.
• Le terme « agile » fait ainsi référence à la capacité
d'adaptation aux changements de contexte et aux modifications
de spécifications intervenant pendant le processus de
développement.
• Comment:
visent à réduire le cycle de vie d'un logiciel
accélérer son développement en:
Développant une version minimale,
En intégrant les fonctionnalités par un processus
itératif basé sur une écoute client
Tests tout au long du cycle de développement.
102 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
MÉTHODES AGILES:
• Objectifs des méthodes agiles :
Augmenter le niveau de satisfaction client
Faciliter le travail de développement
Performance
Qualité
• Méthodes adaptatives Vs prédictives
• Les pratiques des méthodes agiles :
Souvent anciennes, admises et testées "bon sens"
Mais en général oubliées "pas de mise en pratique"
Exemple significatif: les pratiques relatives aux tests
• Grâce aux méthodes agiles, le client est pilote à part
entière de son projet et obtient très vite une première mise
en production de son logiciel. Ainsi, il est possible
d'associer les utilisateurs dès le début du projet
103 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
MÉTHODES AGILES:
• Objectifs des méthodes agiles :
Augmenter le niveau de satisfaction client
Faciliter le travail de développement
Performance
Qualité
• Les pratiques des méthodes agiles :
Souvent anciennes, admises et testées "bon sens"
Mais en général oubliées "pas de mise en pratique"
Exemple significatif: les pratiques relatives aux tests
• Grâce aux méthodes agiles, le client est pilote à part
entière de son projet et obtient très vite une première mise
en production de son logiciel.
il est possible d'associer les utilisateurs dès le début
du projet.
104 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
MÉTHODES AGILES: DÉTAILS
• En février 2001, les instigateurs des principales méthodes
agiles forment l’Agile Alliance. Leur réflexion aboutit au
"Manifesto for Agile Software development" qui définit
4 valeurs:
Les individus et leurs interactions plus que les processus et
les outils.
Du logiciel qui fonctionne plus qu’une documentation
exhaustive.
La collaboration avec les clients plus que la négociation
contractuelle.
L’adaptation au changement plus que le suivi d’un plan.
105 COURS CONCEPTION ORIENTÉE OBJET – UML2
NOTIONS SUR LE GÉNIE LOGICIEL
MÉTHODES AGILES: 12 PRINCIPES
1. Livraison ASAP de versions fonctionnelles ( feedback)
2. Le changement comme avantage concurrentiel
3. Livraisons intermédiaires aussi souvent que possible
4. Coopération quotidienne entre utilisateurs et développeurs
5. Construction d’une équipe motivée
6. Favoriser l’échange oral sur l’écrit
7. 1er indicateur d’avancement du projet : le fonct. de
l’application
8. Rythme soutenable pour les utilisateurs et les développeurs
9. Attention continue à l’excellence technique et à la conception
10.Toujours favoriser la simplicité
11.Responsabilité confiée à l’équipe entière et volontariat
12.Auto-ajustement de l’équipe pour améliorer son efficacité
106 COURS CONCEPTION ORIENTÉE OBJET – UML2