Conception Orientée Objet UML 2

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



































http://www.commentcamarche.net/contents/477-methodes-agiles-rad-xp
















https://en.wikipedia.org/wiki/Denver_International_Airport








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

http://www.larousse.fr/dictionnaires/francais/mat%C3%A9riel/49844

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:




• 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 ?



• 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)




• À 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.




• 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




• 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




• 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…


– Pression du client, du marché…




• 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


– Programmation de bas niveau du système




• 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




• 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)




• 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 !




• Premier vol d’Ariane 5 (1996) (suite 3)


– Mauvaise appréciation du rôle et des limites du

logiciel

– Gestion de projet défectueuse










– Complexité





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.



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




• 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




• 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




• 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




• 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 !




• 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







– Tests d’intégration – Langages de programmation


– Complexité





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.




• 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




• 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










– Complexité





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




• 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




• 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.




• « 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é



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



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 !



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…

– …




• 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




• 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




• 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




• 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…




• 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



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




• 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é




• 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 !



• 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 ?



• 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




• 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;




• 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



• 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




• 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.




• 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



• 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



• 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



• 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.



• 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)



• PASSAGE DE LA PROGRAMMATION "IN THE SMALL" À LA PROGRAMMATION "IN THE LARGE"

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)



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)



• 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



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



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.



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




• 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




• 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




• 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




• 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 !



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



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.



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


https://fr.wikipedia.org/wiki/Bonnes_pratiques



https://fr.wikipedia.org/wiki/Ing%C3%A9nierie


• 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:



• 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



• 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É):



EN RÉSUMÉ, LES QUALITÉS D'UN 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



• 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É



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)



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)



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)



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)



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)



• 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)



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)



• La 1ère tentative : séparation de l'analyse et de

l'implémentation

LES MODÈLES

Analyse

Implémentation



– 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)


EX.2. DÉVELOPPEMENT EN CASCADE (WATERFALL)

Analyse des

besoins

Spécification

Conception

Codage

Test

Validation

Recette


Recette: vérification de conformité d'un produit.


• Inconvénient :

– Pas de validation

intermédiaire

– Pas d’adaptabilité

• Conséquences :

– Erreur d’analyse et

évolution coûteuse

(effet tunnel)




• 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




• 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:



• 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



• 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



• 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%


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


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.



• 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:



• 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



• 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



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 »


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.


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.



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



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.



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



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.



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.



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é


Conception Orientée Objet UML 2

Documents

Transcript of Conception Orientée Objet UML 2