CHAPITRE I:CONCEPTION DE LOGICIEL

1 Introduction

La conception de logiciel met en oeuvre tout un ensemble d'activités qui à partir d'une demande d'informatisation d'un processus (demande qui peut aller de la simple question orale jusqu'au cahier des charges complet) permettent la conception, l'écriture et la mise au point d'un logiciel (et donc de programmes informatiques) jusqu'à sa livraison au demandeur.

2. Définitions

1. Un logiciel ou application est un ensemble de programmes, qui permet à un ordinateur ou à un système informatique d'assurer une tâche ou une fonction en particulier. 

Exemples : logiciel de gestion de la relation client, logiciel de production, logiciel de comptabilité, logiciel de gestion des prêts.

On distingue en général, dans un système informatique, la partie matérielle (l'ordinateur et ses périphériques) et la partie logicielle, immatérielle (les programmes ? écrits ? sur le disque dur).

Le terme logiciel est souvent employé pour désigner un programme informatique, et inversement, bien qu'un logiciel puisse être composé d'un seul ou d'une suite de programmes.

Ce dernier cas est d'autant plus fréquent que la capacité réduite de calcul de l'ordinateur oblige à une segmentation des tâches en plusieurs modules séparés ; cependant, les énormes capacités des micro­ordinateurs actuels en regard des applications typiques de la bureautique ont permis la réalisation d'applications monolithiques.

Généralement, les programmes sont accompagnés d'un ensemble de données permettant de les faire fonctionner (par exemple, un jeu viendra avec de nombreuses images, animations, sons, etc.).

Pour fonctionner, un logiciel nécessite l'utilisation d'un ordinateur (micro­ordinateur, station de calcul, mainframe, supercalculateur, etc.) sur lequel existe à l'origine un ? logiciel­moteur ? (système d'exploitation) qui accepte le ? logiciel­application ?.

Le tout a besoin d'une alimentation électrique.

? 2. Les licences 

Le droit d'utilisation du logiciel est généralement règlementé par une licence d'utilisation et le droit d'auteur.

Les grandes familles de licences les plus connues sont :

• les licences autour du logiciel libre (free software en anglais) ; • le gratuiciel (freeware) ; • le partagiciel (shareware) ; • d'autres types de licences, telles que les licences monoposte ou multiposte ; 

• certains logiciels enfin sont internes à des entreprises et leur diffusion est interdite. 

3. Diverses présentations de logiciels 

Les programmes peuvent être de différentes formes :

• exécutables : ils peuvent être exécutés directement par l'ordinateur ; • généralement, ils ne peuvent être exécutés que sur un type de machine et de système 

d'exploitation particulier (exemple : Microsoft Windows sur un compatible PC) ; • cependant, il existe des exécutables (en bytecode) exécutables sur une variété de 

plates­formes (comme ceux du langage Java) ; ils visent en fait l'exécution pour une machine virtuelle, qui est elle­même un logiciel disponible sur les diverses plates­formes. 

• fichiers sources : il s'agit généralement d'un texte respectant les règles d'écriture d'un langage de programmation particulier ; à titre indicatif, l'ordre de grandeur de la taille d'un logiciel comme Microsoft Word est d'un million de lignes de code ; 

• pour un langage compilé : ils doivent être traduits en un exécutable par un compilateur ; 

• pour un interpréteur : ils sont exécutés directement à la lecture (par exemple des scripts Perl ou PHP). 

• bibliothèques    : il s'agit de programmes exécutables ou source qui, en eux­mêmes, ne sont pas exécutables directement et n'offrent pas de fonctionnalité à l'utilisateur, mais fournissent des services à d'autres programmes (par exemple, on trouvera des bibliothèques permettant à un programme de charger des animations ou de jouer des sons) ; on trouve en particulier des bibliothèques dynamiques (dll Windows ou so GNU/Linux). 

• Les données associées au logiciel peuvent également être de différents formats : fichiers classiques, bases de données (relationnelles, hiérarchiques, etc.). Les données du logiciel peuvent être éclatées en un grand nombre de fichiers, ou tout le logiciel peut être rassemblé en un seul fichier ; par exemple, sous Windows, la définition de l'interface utilisateur, le dessin des icônes etc., sont souvent intégrés dans le même fichier que l'application principale.

? 4. Développement de logiciels 

Le développement de logiciel comprend l'ensemble des étapes et processus qui permettent de passer de l'expression d'un besoin informatique à un logiciel fonctionnel et fiable.

Le standard international CMMI recommande, pour un premier niveau de maturité du développement de logiciel, la maîtrise de 7 processus­clés :

• gestion des exigences (spécifications) ; • planification de projet    ; • supervision et suivi de projet    ; • gestion des achats ; • assurance qualité    ; • gestion de configuration ; 

• mesures et analyses. Les logiciels, suivant leur taille, peuvent être développés par une personne seule, une petite équipe, ou un ensemble d'équipes coordonnées. Le développement de grands logiciels par de grandes équipes pose de grands problèmes de coordination, en raison de la quantité importante d'informations à communiquer entre les intervenants : documentation, réunions. Pour ces raisons, le développement de logiciels dans un contexte professionnel suit souvent des règles strictes permettant le travail en groupe et la maintenance du code ; en effet, souvent, les personnes qui doivent opérer des modifications ultérieures dans le code ne sont plus les personnes qui l'ont développé.

Un nouveau modèle de développement tend cependant à se répandre : le bazar (modèle utilisé pour la conception de GNU/Linux)

Un logiciel en version béta (ou béta­test) est un logiciel non finalisé, pour lequel on effectue une série de tests jusqu'à ce qu'une stabilité relative soit atteinte. Les personnes qui cherchent les dernières failles de ces versions de logiciels sont appelés des béta­testeurs.

CHAPITRE II:CAPABILITY MATURITY MODEL INTEGRATION

2.1 Historique 

Dans les années 1980, le DoD (Department of Defense) américain a demandé l'élaboration d'un référentiel de critères lui permettant d'évaluer ses fournisseurs de logiciel. Après une lente maturation, le SEI (Software Engineering Institute) financé par le DoD a présenté en 1991 le CMM (Capability Maturity Model). Ce modèle de référence ne concerne que les bonnes pratiques du génie logiciel. Après un fort engouement pour ce modèle, d'autres modèles similaires ont vu le jour, tels que :

• SE­CMM (pour System Engineering) ; • SA­CMM (pour Software Acquisition) ; • IPD­CMM (pour Integrated Product Development) ; • People CMM    pour le management des ressources humaines ; 

• SS­CMM pour Supplier Sourcing. 

Tant et si bien qu’il fallut rebaptiser le CMM ? initial ? en SW­CMM (pour Software).

En 2001, le SEI a proposé une nouvelle version de son modèle, le CMMI (Capability Maturity  Model Integration) qui englobe les bonnes pratiques des autres modèles, sauf la gestion des ressources humaines qui n'est pas encore considérée. La version actuelle du modèle a été réactualisée en 2006.

? 2.2 Descriptif du modèle 

Dans l'approche étagée (il existe une approche dite "continue"), les bonnes pratiques préconisées par le modèle sont rassemblées en 22 domaines de processus eux­mêmes regroupés en 5 niveaux de maturité :

• Initial : Les facteurs de réussite des projets ne sont pas identifiés, la réussite ne peut donc être répétée (par dérision, ce niveau est aussi nommé héroïque ou 

chaotique). • Reproductible : Les projets sont pilotés individuellement et leurs succès sont 

répétables. • Défini : Les processus de pilotage des projets sont mis en place au niveau de 

l'organisation par l'intermédiaire de normes, procédures, outils et méthodes. • Géré : La réussite des projets est quantifiée. Les causes d'écart peuvent être 

analysées. • Optimisé : La démarche d'optimisation est continue. 

Le niveau 1Le niveau 1 Initial est le niveau plancher. Les résultats sont imprévisibles (respect engagements) ; l’atteinte des résultats repose plus sur les hommes, sur leur engagement et bonne volonté, que sur l’application disciplinée de bonnes pratiques définies. Image : ca peut marcher mais en courant dans tous les sens : instabilité.

Le niveau 2 Le niveau 2 est orienté Projet. Ce niveau assure que les pratiques basiques de gestion de projet sont toujours mises en ?uvre (gestion des exigences, estimations de charge argumentées, suivi de projet, mesure d’indicateurs, contrôle qualité, …), même dans les contextes difficiles. Les projets respectent généralement leurs engagements. La discipline s’exerce projet par projet. Certains processus sont maîtrisés ; il est possible de les répéter. 7 domaines de processus sont regroupés au niveau de maturité 2

• Gestion des exigences    : Gérer les exigences des produits et des composants produit du projet et identifier les incohérences entre ces exigences et les plans et produits intermédiaires du projet. 

• Planification de projet : ?tablir et maintenir des plans qui définissent les activités du projet. 

• Suivi et pilotage de projet : Faire comprendre l'avancement du projet de sorte que des actions correctives appropriées puissent être prises quand l'exécution du projet s’écarte de manière significative du plan. 

• Assurance qualité des produits et des processus : Fournir aux équipes et au management une visibilité objective sur les processus mis en ?uvre et les produits intermédiaires associés. 

• Mesure et analyse : Développer et maintenir une capacité à mesurer qui réponde aux besoins d'information de gestion. 

• Gestion des accords avec les fournisseurs : Gérer l'acquisition de produits fournisseurs pour lesquels il existe un accord formel. 

• Gestion de configuration : ?tablir et maintenir l'intégrité des produits intermédiaires en utilisant l'identification, le contrôle de configuration, l'enregistrement des états de configuration, et les audits de configuration. 

Le niveau 3Le niveau 3 est Défini. A ce niveau, l’organisation dispose d’un ensemble de processus standard, qui 

sont adaptés par chaque projet. Chaque projet capitalise son expérience et permet de bonifier le capital collectif.

Le niveau 4 Le niveau 4 est Géré Quantitativement. A ce niveau, les processus clés sont sous contrôle statistique (surveillance d’indicateurs quantitatifs, et actions correctrices si dérives). ?limination des causes spéciales de variation.

• Ex. la capitalisation a permis d’établir la productivité moyenne du processus (taille produite/charge consommée). Le projet se fixe un objectif de productivité en relation et prend des mesures dès qu’il y a des dérives. 

Le niveau 5Le niveau 5 est Optimisé. L’organisation est dans une boucle permanente d’amélioration continue. Des analyses causales statistiques menées régulièrement permettent ces améliorations.

? Pour aller plus loin Et l'ISO 9001 dans tout ça ?

• Les deux normes concernant les processus de développement logiciel, un article de comparaison peut­être consulté Comparaison entre ISO 9001 et CMMI 

CMMI et ISO 15504 alias SPICE

• CMMI, utilisé en mode continu, est un des modèles de processus accepté par la norme ISO 15504 

• Liens externes 

• SEI ­ CMMI    • mini CMMI­survey   , 2007, SQI Hungarian Software Quality Consulting Isntitute Ltd.. 

Consulté le 07 August  2007 

• Bibliographie Livres sur le CMMI

• Richard Basque, Un itinéraire fléché vers le Capability Maturity Model Intégration  ­ Version 1.2 , éditions DUNOD, 2006. 

• Dennis M. Ahern, Comprendre CMMI, une introduction pratique à l'amélioration de processus, traduction : Q­Labs, CEPADUES­EDITIONS, 2006. 

CHAPITRE III: BOGUES

3.1 Définitions

Un bogue ou bug informatique est une anomalie dans un programme informatique l’empêchant de fonctionner correctement. Sa gravité peut aller de bénigne (défauts d’affichage mineurs) à majeure (explosion du vol 501 de la fusée Ariane 5).

Les bogues sont généralement dus à un problème de conception du logiciel ; l'erreur peut parfois être identifiée (et la correction effectuée simplement), mais elle peut aussi bien provenir de la conception même du programme, ce qui nécessite une refonte profonde. Plus rarement, les bogues dans les logiciels peuvent être dus à des erreurs dans les outils de développement utilisés par les programmeurs du logiciel. Enfin, le matériel lui­même peut comporter des bogues, comme ce fut le cas du bogue de la division du Pentium qui a affecté les premières versions de ce processeur.

Le terme est dérivé du mot anglais bug (bestiole), venant du jargon des ingénieurs de matériel et représentant les erreurs de matériel qui survenaient. Le terme est parfois faussement attribué à Grace Hopper : une anecdote raconte qu'elle aurait découvert qu'un insecte (bug), coincé entre deux contacts du relais qui faisait fonctionner l’appareil, était la raison du mauvais fonctionnement d’un des premiers ordinateurs électromécaniques.

En 1946, Hopper a rejoint la faculté de Harvard au laboratoire où elle a continué son travail sur Harvard Mark II et Harvard Mark III. Elle a attribué une erreur dans Mark II à un papillon nocturne pris dans un relais, créant le terme bug. L’insecte fut enlevé avec soin et placé dans un journal de bord. Cette première anomalie a popularisé l’expression bug ou bogue pour représenter les erreurs dans un programme.[1] 

Malgré l’intérêt de l’anecdote ci­dessus, il est reconnu que l’utilisation du mot bug pour décrire les défauts de systèmes mécaniques date d’au moins avant les années 1870. Thomas Edison, entre autres, utilisait le mot dans ses notes. Si l'origine précise du mot est donc incertaine, le rapprochement avec les dysfonctionnements dus à la présence d'un insecte dans le système semble évident.

Le terme anglais bug vient du français ? parasite ?. En France, c'était le terme utilisé par les électriciens pour les problèmes de lignes utilisé sous la forme ? la ligne est parasitée ?. Adapté en anglais il est devenu bug puis est revenu en France sous la forme de ? bogue ? (de châtaigne ?) sous l’égide de la DGLF. Bug reste très largement utilisé.

En France, le terme ? bogue ? est recommandé par la Délégation générale à la langue française et aux langues de France (DGLF) depuis un arrêté paru au Journal officiel du 30 décembre 1983. Ce mot, qui se veut plus français, n'exprime pas une étymologie. C'est pourquoi peu de gens utilisent la version francisée. ? cette époque le genre féminin était préconisé.

Cependant à la fin de la décennie 1990, les dictionnaires tels que le ? Nouveau petit Robert ? et ? Le Petit Larousse illustré ? rapportaient l’usage de ce terme au masculin, sans doute sous l’influence québécoise où l’Office québécois de la langue française (OQLF) prônait depuis longtemps l’emploi du genre masculin. Le terme français a été popularisé avec le fameux bogue de l'an 2000 qui, sans avoir entraîné de dysfonctionnement visible majeur, a néanmoins nécessité beaucoup de travaux de transformation des systèmes d'information dans la décennie 1990.

Désormais la DGLF recommande aussi le genre masculin pour ce mot.

? 3.2 Effets 

Les pessimistes disent qu'il y a des bogues dans tous les programmes informatiques. En revanche, les programmes de qualité contiennent relativement peu d'erreurs et n'empêchent généralement pas le système de continuer ses tâches. Au contraire, les programmes moins bons, quelquefois dits bogués, contiennent beaucoup d’anomalies qui interfèrent souvent avec le fonctionnement du système.

Les bogues ont des effets qui varient grandement. Quelques­uns ont un effet subtil sur le fonctionnement du logiciel et peuvent demeurer inconnus pendant une longue période. D'autres sont plus sévères et peuvent arrêter le logiciel voire bloquer le système.

Dans certains cas, sur les systèmes d’exploitation, les bogues de logiciels peuvent rendre instable le système jusqu’à ce qu’il soit rechargé.

D'autres erreurs de programmation peuvent mener à des failles de sécurité ; le dépassement de tampon est un des bogues les plus communs permettant à un pirate informatique d'exécuter un nouveau programme sur la machine cible.

Les bogues peuvent avoir des répercussions économiques considérables. Steve McConnell a comptabilisé plusieurs bogues qui ont coûté plus de 100 millions de dollars US.

• Un des cas les plus spectaculaires est celui de la fusée européenne Ariane 5, qui a coûté plus d'un milliard de dollars. Quelques instants après le décollage, elle fut détruite à cause d'une erreur de l'ordinateur de guidage embarqué à bord de l'appareil. Toutefois, dans ce cas, le terme "bogue" est quelque peu impropre : en effet, "l'erreur" a consisté à reprendre à l'identique l'ordinateur et le logiciel utilisé sur Ariane 4 pour la gestion des centrales inertielles de guidage, ordinateur et logiciel qui fonctionnaient parfaitement sur cette fusée. Cependant le reste du système informatique d'Ariane 5 travaillait avec des nombres de 64 bits en virgule flottante alors que ces éléments travaillaient avec des nombres de 16 bits en entier signé. Lors du passage de valeurs d'un système à l'autre est apparu une exception matérielle (plus précisément, un dépassement arithmétique, ou les nombres de 64 bits ont une trop grande valeur pour être représentés en 16 bits, ce qui a fait partir le comportement par défaut de gestion d'erreur : un autotest), ce qui a eu pour effet une déviation de la trajectoire impossible à rectifier depuis le sol. 

• La sonde de Vénus Mariner 1 fut perdue d’une façon similaire en 1962. Un trait d’union oublié dans un programme Fortran a coûté plus de 80 millions de dollars. D’après Arthur C. Clarke, ce fut le ? plus coûteux trait d’union de l’histoire ?. 

• Le fameux bogue de l'an 2000, a enrichi les entreprises de conseil en informatique, mais a fait dépenser des fortunes aux entreprises qui ont bien été obligées de modifier la majorité de leurs logiciels, dans la crainte que ceux­ci ne traitent pas correctement les quatre chiffres des années et se retrouvent en 1900 au 1er janvier 2000. 

3.3 Approche formelle : les méthodes formelles 

Un bogue est un non­respect de la spécification du système, c’est­à­dire de la définition de ce que le système est censé faire. Une spécification peut être informelle et vague (comme : ? le logiciel est un traitement de textes qui ne provoque pas d’erreur à l’exécution ?), ou formelle et précise (? tri(t) est 

une permutation de t telle que tri(t) est ordonnée pour la relation < ?), y compris au point d’obtenir des formules mathématiques. Un programme bogué est un programme dont la mise en ?uvre ne vérifie pas la spécification.

On peut se demander s’il existe des méthodes universelles, sans faille et automatiques qu’il suffirait de suivre pour se rendre compte si un programme est bogué ou non. La réponse est non. En effet, si une telle méthode existait, il serait possible de l’automatiser par un ordinateur, c’est­à­dire par un logiciel d’analyse. Cet analyseur devrait opérer sur des programmes à analyser quelconques et devrait, par exemple, répondre à la question suivante : ? l’état final du programme peut­il être un état d’erreur à l’exécution, ou est­il forcément un état correct (ou une non­terminaison) ?. Or, le théorème de Rice dit qu’on ne peut répondre à cette question sur un système à état infini. Plus généralement, toute question de spécification portant sur l’état final du programme est indécidable, c’est­à­dire qu’un logiciel ou une méthode automatique ne peut y répondre, sauf les questions dont la réponse est toujours vraie ou toujours fausse.

On pourrait objecter que les ordinateurs sont des systèmes à état fini : chaque ordinateur a une quantité finie de mémoire. Cependant, à l’exception de systèmes de très petite taille, il convient, à des fins d’analyse, de considérer les ordinateurs comme des systèmes à mémoire non bornée. En effet, les techniques d’analyse utilisant la finitude de l’état vont toutes, de façon plus ou moins détournée ou optimisée, chercher à énumérer les états du système. Un système à n bits de mémoire a 2n états ; dans un ordinateur personnel actuel, n est de l’ordre de 238. On voit donc que toute tentative d’énumération des états du système est vouée à l’échec.

L’impossibilité de la recherche automatique universelle des bogues est donc un problème d’ordre fondamental, et non une limitation de la technologie actuelle.

? 3.4 Comment en faire ? Comment s’en défaire ? 

Les bogues sont une conséquence de la nature de la tâche de programmation. Quelques­uns surviennent à cause de simples erreurs d’inattention d’un programmeur écrivant du code source. D’autres bogues sont le résultat d’interférences inattendues entre différentes parties d’un logiciel, voire de comportements imprévus de systèmes extérieurs au logiciel (capteurs défaillants qui retournent des valeurs fantaisistes). Certains, enfin, relèvent de la non­prise en compte des termes exacts des normes définissant les langages et les bibliothèques employées par les programmeurs (cf. exemple). Ces situations arrivent parfois quand les logiciels deviennent trop complexes pour que les programmeurs puissent penser à toutes les possibilités d’interaction entre plusieurs parties d’un programme.

L’industrie du développement logiciel fait de gros efforts pour trouver des méthodes de prévention des erreurs des programmeurs menant à des bogues. Cela inclut :

•    Les règles de programmation . On s'impose l’uniformité du style d’écriture (réduitla confusion possible pour les autres développeurs) et l’écriture de documentations détaillées. Typiquement, l’écriture de programmes devra suivre un processus formalisé en étapes successives et documentées. 

• Les techniques de programmation. Un bogue peut parfois créer des incohérences dans les données internes d’un programme en fonctionnement. Les programmes peuvent être écrits pour vérifier la cohérence des données internes durant leur exécution. Si un problème est trouvé, le logiciel peut s’arrêter immédiatement pour que le bogue puisse être trouvé et réparé, ou simplement avertir l’utilisateur, essayer de corriger l’incohérence et continuer à fonctionner. De plus, on peut 

interdire ou du moins sévèrement réglementer l’usage de fonctionnalités de maniement délicat du langage de programmation ou du système. 

•    Les méthodologies de développement. Il y a plusieurs méthodes pour gérer l’activité des programmeurs afin de minimiser les risques de bogues. Plusieurs de ces techniques relèvent de la spécialité du génie logiciel. 

•     Le support des langages de programmation. Les langages incluent parfois des fonctionnalités qui aident les programmeurs à traiter les bogues, comme le traitement des exceptions. De plus, plusieurs langages récents ont délibérément exclu des fonctions avancées susceptibles de mener à des bogues. Par exemple, les langages Java et Perl n'offre pas d'accès de bas niveau aux pointeurs, évitant qu’un programme n’accède à une zone de la mémoire par inadvertance. 

•      Le test. Le logiciel est essayé dans diverses configurations, notamment des configurations difficiles et ? extrêmes ?. On va aussi tenter de couvrir toutes les fonctionnalités, ou toutes les portions de code du logiciel, ou tous les chemins dans le code (ce dernier critère est en général impossible à atteindre). Cependant, le test ne donne pas d’assurance sur le bon fonctionnement du logiciel dans tous les cas, car il ne tient compte que d’un nombre limité de configurations du système, d’entrées des utilisateurs ou du monde extérieur, etc. 

•     Les méthodes formelles. Il s’agit ici de parvenir à une preuve, au sens mathématique, de bon fonctionnement du logiciel. La méthode peut fournir plus au moins d’automatisation : les assistants de preuve aident un utilisateur à formuler une preuve mathématique et la vérifient ; le model checking et l’analyse statique par interprétation abstraite sont automatiques ; il existe des gradations intermédiaires. Citons par exemple la Méthode B, utilisée pour la ligne 14 (Meteor) du métro parisien. 

Trouver et corriger les bogues, ou déboguer, est une partie majeure de la programmation de logiciels. Maurice Wilkes, pionnier de l’informatique, décrit ses réalisations des années 1940 en disant que l’essentiel du reste de sa vie serait occupé à réparer les erreurs dans ses propres programmes. Alors que les programmes informatiques deviennent de plus en plus complexes, les bogues deviennent plus fréquents et difficiles à corriger. Quelquefois, les programmeurs passent plus de temps et d’efforts à trouver et à corriger les bogues qu’à écrire du nouveau code.

Habituellement, la partie la plus difficile du débogage est de trouver la partie du code responsable de l’erreur. Une fois localisée, la corriger est souvent facile. Des programmes appelés débogueurs existent afin d’aider les programmeurs à trouver les bogues. Toutefois, même avec l’aide d’un débogueur, dénicher un bogue est une tâche souvent très difficile.

Ordinairement, la première étape pour trouver un bogue est de trouver un moyen de le reproduire facilement. Une fois le bogue reproduit, le programmeur peut utiliser le débogueur ou un autre outil pour observer l’exécution du programme dans son contexte habituel, et éventuellement trouver le problème. En revanche, il n’est pas toujours facile de reproduire un bogue. Certains sont causés par des entrées au logiciel qui peuvent être difficiles à reproduire pour le programmeur. D’autres peuvent disparaître quand le programme est lancé dans un débogueur; ceux­ci sont appelés heisenbugs (faisant, par plaisanterie, référence au principe d'incertitude de Heisenberg). Enfin, les bogues des programmes parallèles (composés de plusieurs modules s’exécutant de façon concurrente, par exemple sur plusieurs processeurs) sont souvent difficiles à reproduire s’ils dépendent de l’ordonnancement précis des calculs sur la machine.

? 3.5 Exemple 

Exemple de code non bogué mais pouvant provoquer une erreur et correction du code pour un fonctionnement détectant les erreurs des autres programmes ou de la machine.

• Le pseudo­code suivant représente une fonction prenant en entrée une adresse mémoire et incrémentant la valeur qui y est stockée. 

       fonction IncPointeur( pointeur )      *pointeur ++

 fin fonction

• Le problème est que dans les systèmes informatiques, il est fréquent que seule une portion de la mémoire soit accessible en écriture et qu’une tentative de le faire dans une zone mémoire protégée ou inexistante, provoque un bogue, une interruption du programme ou au pire, un arrêt du système. 

• Dans les systèmes complexes, il est souvent difficile et fastidieux de prévoir tout les cas possibles, c’est pourquoi la tolérance totale n’existe pas. Ceci n’empêche pas de prévoir un maximum de cas pour rendre le programme le plus robuste possible. 

   fonction IncPointeur( pointeur )       si EstValide( pointeur )           *pointeur ++           retour OK       sinon           retour ERREUR       fin si   fin fonction

• Dans le pseudo­code ci­dessus, le programme teste la validité de l’adresse avant d’y accéder, ce qui permet au programme de continuer même si une adresse erronée lui est transmise. 

3.6 Humour et citations célèbres liées aux bogues 

•  Ce n’est pas un bogue, c’est une fonctionnalité !? (de l’anglais It’s not a bug, it’s a  feature). ­ Réponse fréquente des développeurs de logiciels à leurs utilisateurs. 

•  Tout programme non trivial possède au moins un bogue ? (de l’anglais Every non­trivial program has at least one bug) ­ Tiré de la loi de Murphy appliquée à l’informatique (Cf. : liens externes ci­dessous) 

•  L’erreur est humaine, mais un vrai désastre nécessite un ordinateur ? •  Quand un logiciel n'a plus aucun bogue, il est habituellement désuet ? 

3.7 Jeux vidéo

Le terme de bogue dans les jeux vidéo a pour signification première une erreur dans le déroulement supposé d'une action. La résultante finale du bogue n'occasionnera pas la même gêne suivant son intensité. Une main d'un joueur traversant un mur dans un jeu de tir subjectif n'aura pas la même nuisance qu'une impossibilité d'accomplir la quête principale d'un jeu de rôles.

L'existence des bogues n'apportent pas que des points négatifs :

• La recherche et la correction de bogues démontrés permettent souvent une correction d'autres bogues inconnus à ce jour et/ou une optimisation du code source, ce qui est très profitable au joueur (jouabilité améliorée) comme au développeur (le support technique régulier d'un jeu est un gage de renommée). 

• La popularité exceptionnelle d'un jeu qui connaît toutefois des bogues est souvent initiateur d'une communauté très prolifique capable de corriger ces bogues à l'aide de différents outils. Le jeu le plus symbolique de ce phénomène est certainement Fallout 2. 

• Certains bogues peuvent être profitables à des joueurs plus ou moins mal intentionnés. Dans les parties jouable en réseau (sur Internet ou en réseau local), les bogues exploitables sont duaux : soit ils sont source de destruction du fair play (notamment dans les jeux de tir subjectif), soit ils permettent une avancée spectaculaire et consentante entre les joueurs. 

• Dans les concours de Speedrun, certains bogues sont très profitables afin de finir un jeu ou une séquence le plus rapidement possible. 

Le terme de bogue englobe d'autres notions moins usitées à cause de la popularité du nom de bogue. Il serait judicieux de nommer certaines erreurs par oubli plutôt que par bogue.

? 3.8 types de bogues particuliers ? Mandelbug    ? Schrödinbug    ? Heisenbug    

? Bohr bug     

? Liens internes ? Développement de logiciel    ? Explorer la catégorie:Développement logiciel ? Therac­25    ? Débogueur    

? Liens externes ? http://www.murphys­laws.com/murphy/murphy­computer.html    : loi de Murphy appliquée à l’informatique. 

? Note 1 Le départ de l'intrigue du film Brazil est une illustration de cette anecdote : une insecte 

provoque un court­circuit dans une machine, transformant le nom Tuttle en Buttle ; ici, le bug met à jour les excès de la bureaucratie. 

Des erreurs de conception dans les logiciels peuvent causer des comportements incorrects, souvent appelés  bogues.  La  gravité   de   ceux­ci  peut   aller  de   très  mineure   (p.ex.,   apparence   légèrement incorrecte d'un élément d'interface graphique), à des évènements catastrophiques (explosion de la fusée Ariane vol 501, irradiation incorrecte de patients par une machine de traitement...) en passant par des pertes plus ou moins grandes de données, et, rarement, par une détérioration du matériel.

Il est difficile, pour des raisons fondamentales, de produire des logiciels sans bogue ; cependant, il existe des mécanismes par lesquels on peut limiter la quantité de bogues, voire les supprimer. Citons d'une part des préceptes d'organisation des équipes de programmation et leur méthodologie, d'autre part les technologies de recherche de bogues dans les logiciels. La recherche en informatique a développé un domaine d'étude, la vérification formelle, dont l'objectif est de certifier la qualité des logiciels et de garantir leur fiabilité. Dans l'ensemble, l'obtention de logiciels complexes peu bogués est   coûteuse   en   hommes   et   en   temps.   Plus   les   anomalies   sont   détectées   tôt   au   long   du développement du logiciel, moins leur correction est coûteuse.

CHAPITRE IV. AUTRES NOTIONS

?  1. Ouverture du code source 

On classe les logiciels d'après la disponibilité du code source et de la licence qui régit la distribution du programme :

• code ouvert    : tout le monde peut lire le code source. Ce terme n'est pas synonyme de logiciel libre ; 

• code fermé    : le code source n'est disponible que pour une minorité de personnes ; • logiciel libre    : tout le monde peut étudier, copier, modifier et distribuer des versions 

modifiées du logiciel (définition de la free software foundation). Les logiciels libres sont protégés pour la plupart par une licence d'utilisation ; Pour autant cela ne signifie pas que le logiciel est gratuit. 

• logiciel propriétaire    : au moins un de ces droits n'est pas rempli pour les utilisateurs. La plupart du temps, acquérir une licence d'utilisation nécessite le paiement d'une certaine somme aux créateurs du logiciel ; 

• logiciel commercial    : logiciel destiné à la vente, il peut être libre ou propriétaire. 

2 . Développeurs 

Voir ou créer l'article : Liste d'éditeurs de logiciels bureautiques.Article détaillé : Liste des éditeurs de jeux vidéo.

3. Logiciels critiques 

Article détaillé : Profil d'application.

Pour la sécurité globale des systèmes d'information d'une entité, il peut être nécessaire de définir des profils d'application, afin d'identifier les logiciels critiques sur lesquels il est nécessaire de porter 

une attention particulière du point de vue de la sécurité.

4. Programme informatique et langages

Langages de programmationLangages à objetsC++ ­ C# ­ DDelphi ­ Eiffel ­ GroovyJava ­ Python ­ RubySimula ­ SmalltalkVisual Basic ­ Lisaac ­ WinDevLangages impératifsAPL ­ ASP ­ AssembleurBASIC ­ C ­ CobolForth ­ Fortran ­ LimboLogo ­ Pascal ­ Perl ­ PHPLangages fonctionnelsHaskell ­ ML/OCamlLisp/Common LispScheme ­ XSLTLangages déclaratifsClips ­ PrologLangages concurrentsAda 95 ­ ErlangVoir aussiConception ­ CodageTests ­ Optimisations

Un programme informatique est une liste d'ordres indiquant à un ordinateur ce qu'il doit faire. Il se présente sous la forme d'une ou plusieurs séquences d'instructions, comportant souvent des données de base, devant être exécutées dans un certain ordre par un processeur ou par processus informatique (cas des systèmes multitâches.

La programmation dans le domaine informatique est l'ensemble des activités qui permettent l'écriture des programmes informatiques. C'est une étape importante de la conception de logiciel (voire de matériel, cf. VHDL).

Pour écrire le résultat de cette activité, on utilise un langage de programmation.

La programmation représente usuellement le codage, c’est­à­dire la rédaction du code source d'un logiciel. On utilise plutôt le terme développement pour dénoter l'ensemble des activités lié à la création d'un logiciel.

? Techniques de programmation ? Programmation impérative    

? Programmation structurée    ? Programmation orientée objet    ? Programmation orientée prototype    ? Programmation par contrat    ? Programmation déclarative    ? Programmation fonctionnelle    ? Programmation logique    ? Programmation par contraintes    ? Programmation orientée composant    ? Programmation orientée aspect    ? Programmation concurrente    ? Programmation procédurale    

? Programmation par intention    

1. Sommaire

? 1 Fonction    ? 2 Conception    

? 2.1 Différences    ? 3 Voir aussi    

? 3.1 Liens internes    

? Fonction Un ordinateur sans programme ne fait absolument rien, il attend des instructions. En fait, la capacité à suivre un programme enregistré sert même souvent, d'un point de vue historique, à distinguer un ordinateur d'une simple machine à calculer. Avec cette définition, le premier ordinateur est le Manchester Mark I, premier calculateur à programme enregistré.

? Conception A l'origine d'un programme, il y a un code source écrit par un programmeur dans un langage de programmation compréhensible par le dit programmeur.

Différences 

Selon le langage utilisé, ce code est ensuite soit :

• Traduit avec un jeu d'instructions spécifique à un processeur par un compilateur, ensuite le programme obtenu peut alors être exécuté directement par l'ordinateur. 

• Ou bien est pris en charge par un interpréteur (autre programme), qui décode à la volée les instructions du langage évolué en instructions spécifique au processeur et qui les lui transmet directement pour exécution. 

Parfois le langage de programmation se réduit à un ensemble de symboles correspondant aux 

instructions en code machine. C'est le langage assembleur et, dans ce cas, un programme appelé assembleur est utilisé pour faire la traduction en langage machine.

Le terme ? programme informatique ? est souvent improprement, utilisé comme synonyme de logiciel, les logiciels actuels étant souvent composés de plusieurs programmes. Les logiciels incluent souvent en plus, des fichiers de ressources contenant des données de toutes sortes, celles­ci ne font pas à proprement parlé partie du programme. Par exemple, Microsoft Internet Explorer, Mozilla Firefox, etc. sont des logiciels plutôt que des programmes, car il sont le fruit de la concaténation de multiples programmes exécutant différentes actions et fonctions.

Un programme simple et souvent abstrait est souvent appelé algorithme. Les programmes d'ordinateur sont aujourd'hui souvent les sujets de la logique et des mathématiques : voir les méthodes formelles, la sémantique des langages de programmation, etc.

Liens internes 

Logiciel Programmation informatique Langage de programmation Machine de Turing Forme de Backus­Naur 

En règle générale, la conception de logiciel va suivre 3 grandes phases :

• Phase d'analyse (fonctionnelle) ou de conceptionDurant cette phase, on effectue simultanément l'étude des données et l'étude des traitements à effectuer. C'est en général dans cette phase que s'appliquent les techniques de modélisation. Il en découle la description des bases de données éventuelles à créer et les programmes à écrire et la manière dont tout cela va être intégré. 

• Spécification   • Conception   • Définition de l'   architecture      • Phase de réalisation ou de programmation (écriture et tests des programmes)   •    Algorithmique      • Codage      • Programmation      • Contrôle de version      • Refactoring      • Tests unitaires      • Optimisation du code      • Phase de livraison    • Intégration      • Validation      • Documentation du logiciel      

• Packaging      

CHAPITRE V: PHASE DE RÉALISATION OU DE PROGRAMMATION 

1.AlgorithmiqueOn désigne par algorithmique ou algorithmie l'ensemble des activités logiques qui relèvent des algorithmes. Le mot vient du nom du mathématicien Al Khuwarizmi, qui, au IXe      siècle    écrivit le premier ouvrage systématique sur la solution des équations linéaires et quadratiques. Dans le cas général, l'algorithmique s'effectue au moyen de calculs.

1. Sommaire

? 1 Définition    ? 2 Historique    

? 2.1 Antiquité    ? 2.2    ﾉ      tude systématique    

? 3 Exemples d’algorithme    ? 4 Complexité algorithmique    ? 5 Quelques indications sur l'efficacité des    algorithmes ? 6 Les heuristiques    ? 7 Applications    ? 8 Voir aussi    

? 8.1 Liens externes    

? Définition Un algorithme est un moyen pour un humain de présenter la résolution par calcul d'un problème à une autre personne physique (un autre humain) ou virtuelle (un calculateur). En effet, un algorithme est un énoncé dans un langage bien défini d'une suite d'opérations permettant de résoudre par calcul un problème. Si ces opérations s'exécutent en séquence, on parle d'algorithme séquentiel. Si les opérations s'exécutent sur plusieurs processeurs en parallèle, on parle d'algorithme parallèle. Si les tâches s'exécutent sur un réseau de processeurs on parle d'algorithme réparti ou distribué.

? Historique 

? Antiquité Les algorithmes dont on a retrouvé des descriptions exhaustives ont été utilisés dès l'époque des Babyloniens, pour des calculs concernant le commerce et les impôts.

L'algorithme le plus célèbre est celui qui se trouve dans le livre 7 des Eléments d'Euclide. Il permet de trouver le plus grand diviseur commun, ou PGCD, de deux nombres. Un point particulièrement remarquable est qu'il contient explicitement une itération et que les propositions 1 et 2 démontrent (maladroitement pour nos contemporains) sa convergence.

Etude systématique L'algorithmique a été systématisée par le mathématicien perse Al Khuwarizmi (né vers 780 ­ mort vers 850), auteur d'un ouvrage (souvent traduit par L'algèbre et le balancement) qui décrit des méthodes de calculs algébriques (ainsi que d'un autre introduisant le zéro des Indiens).

Le savant arabe Averroès (1126­1198) évoque une méthode de raisonnement où la thèse s'affine étape par étape (itérativement) jusqu'à une certaine convergence et ceci conformément au déroulement d'un algorithme.   ﾀ la même époque, au XIIe      siècle   , le moine Adelard de Bath a introduit le terme latin de algorismus (par référence au nom de Al Khuwarizmi). Ce mot donne algorithme en français en 1554.

Au XVIIe      siècle   , on pourrait entrevoir une certaine allusion à la méthode algorithmique chez René Descartes dans la méthode générale proposée par le Discours de la méthode (1637), notamment quand, en sa deuxième partie, le logicien français propose de ｫ diviser chacune des difficultés que j'examinerois, en autant de parcelles qu'il se pourroit, et qu'il seroit requis pour les mieux résoudre.ｻ Sans évoquer explicitement les concepts de boucle ou d'itération, l'approche de Descartes prédispose la logique à accueillir le concept de programme, mot qui naît en français en 1677.

L'utilisation du terme algorithme a été remarquable chez Ada Lovelace, fille de lord Byron et assistante de Charles Babbage (1792­1871).

Le substantif algorithmique désigne la méthode utilisant des algorithmes. Le terme est également employé comme adjectif.

Un algorithme énonce une résolution sous la forme d'une série d'opérations à effectuer. La mise en oeuvre de l'algorithme consiste en l'écriture de ces opérations dans un langage de programmation et constitue alors la brique de base d'un programme informatique.

Les informaticiens utilisent fréquemment l'anglicisme implémentation pour désigner cette mise en ?uvre. L'écriture en langage informatique est aussi fréquemment désignée par le terme ｫ codage ｻ, qui n'a ici aucun rapport avec la cryptographie, mais qui se réfère au terme ｫ code source   ｻ pour désigner le texte, en langage de programmation, constituant le programme. L'algorithme devra être plus ou moins détaillé selon le niveau d'abstraction du langage utilisé ; autrement dit, une recette de cuisine doit être plus ou moins détaillée en fonction de l'expérience du cuisinier.

? Exemples d’algorithme Il existe un certain nombre d'algorithmes classiques, utilisés pour résoudre des problèmes ou plus 

simplement pour illustrer des méthodes de programmation. On se référera aux articles suivants pour de plus amples détails :

• tours de Hanoï   , problème célèbre illustrant la programmation récursive ; • algorithme de tri   , ou comment trier un ensemble de nombres le plus rapidement possible ; • huit dames   , placer huit dames sur un échiquier sans qu'elles puissent se prendre entre 

elles ; • algorithme récursif   , quelques présentations d'algorithmes récursifs simples ; • algorithme du simplexe   , qui minimise une fonction linéaire de variables réelles soumises 

à des contraintes linéaires. 

Complexité algorithmique

Les principales notions mathématiques dans le calcul du coût d'un algorithme précis sont les notions de domination (notée O(f(n)), ｫ grand o ｻ), où f est une fonction mathématique de n, variable désignant la quantité d'informations (en bits, en nombre d'enregistrements, etc.) manipulée dans l'algorithme. En algorithmique on trouve souvent des complexités du type :

Notation Type de complexitéO(1) complexité constante (indépendante de la taille de la donnée)O(log(n)) complexité logarithmiqueO(n) complexité linéaireO(nlog(n)) complexité quasi­linéaireO(n2) complexité quadratiqueO(n3) complexité cubiqueO(np) complexité polynomialeO(nlog(n)) complexité quasi­polynomialeO(2n) complexité exponentielleO(n!) complexité factorielle

1. Sans entrer dans les détails mathématiques, on peut dire que lorsque l'on calcule l'efficacité d'un algorithme (sa complexité algorithmique), on cherche à connaître deux données importantes : tout d'abord, l'évolution du nombre d'instructions de base en fonction de la quantité de données à traiter (par exemple, dans un algorithme de tri, le nombre de lignes à trier), que l'on privilégiera sur le coût exact en secondes, ensuite l'appréciation de la quantité de mémoire nécessaire pour effectuer les calculs. Baser le calcul de la complexité d'un algorithme sur le temps ou la quantité effective de mémoire qu'un ordinateur particulier prend pour effectuer ledit algorithme ne permet pas de prendre en compte la structure interne de l'algorithme, ni la particularité de l'ordinateur : selon sa charge de travail, la vitesse de son processeur, la vitesse d'accès aux données, l'exécution de l'algorithme (qui peut faire intervenir le hasard) ou son organisation de la mémoire, le temps d'exécution et la quantité de mémoire ne seront pas les mêmes.

On trouvera dans l'article sur la théorie de la complexité d'autres évaluations de la complexité qui vont en général au delà des valeurs proposées ci­dessus et qui répartissent les problèmes (plutôt que les algorithmes) en classes de complexité.

? Quelques indications sur l'efficacité des algorithmes 

Souvent, l'efficacité d'un algorithme n'est connue que de manière asymptotique, c'est­à­dire pour de grandes valeurs du paramètre n. Lorsque ce paramètre est suffisamment petit, un algorithme de complexité supérieure peut en pratique être plus efficace. Ainsi, pour trier un tableau de 30 lignes (c'est un paramètre de petite taille), il est inutile d'utiliser un algorithme évolué comme le Tri rapide (l'un des algorithmes de tri les plus efficaces en moyenne) : l'algorithme de tri le plus trivial sera suffisamment efficace.

 ﾀ noter aussi : entre deux algorithmes dont la complexité est identique, on cherchera à utiliser celui dont l'occupation mémoire est la plus faible. L'analyse de la complexité algorithmique peut également servir à évaluer l'occupation mémoire d'un algorithme. Enfin, le choix d'un algorithme plutôt qu'un autre doit se faire en fonction des données que l'on s'attend à lui fournir en entrée. Ainsi, le Quicksort (ou tri rapide), lorsque l'on choisit le premier élément comme pivot, se comporte de façon désastreuse si on l'applique à une liste de valeurs déjà triée. Il n'est donc pas judicieux de l'utiliser si on prévoit que le programme recevra en entrée des listes déjà presque triées.

Un autre paramètre à prendre en compte est la localité de l'algorithme. Par exemple pour un système à mémoire virtuelle qui dispose de peu de mémoire (par rapport au nombre de données à traiter), le Tri rapide sera normalement plus efficace que le Tri par tas car le premier ne passe qu'une seule fois sur chaque élément de la mémoire tandis que le second accède à la mémoire de manière discontinue (ce qui augmente le risque de swapping).

Enfin, il existe certains algorithmes dont la complexité est dite amortie. Cela signifie que, pour certaines exécutions de l'algorithme (cas marginaux), la complexité de l'algorithme sera très supérieure au cas moyen. Bien sûr, on n'utilise la notion de complexité amortie que dans les cas où cette réaction est très marginale.

? Les heuristiques 

Pour certains problèmes, les algorithmes ont une complexité beaucoup trop grande pour obtenir un résultat en temps raisonnable, même si l'on pouvait utiliser une puissance de calcul phénoménale. On est donc amené à rechercher une solution la plus proche possible d'une solution optimale en procédant par essais successifs. Puisque toutes les combinaisons ne peuvent être essayées, certains choix stratégiques doivent être faits. Ces choix, généralement très dépendants du problème traité, constituent ce qu'on appelle une heuristique. Le but d'une heuristique est donc de ne pas essayer toutes les combinaisons possibles avant de trouver celle qui répond au problème, afin de trouver une solution approchée convenable (qui peut être exacte dans certains cas) dans un temps raisonnable. C'est ainsi que les programmes de jeu d'échecs, de jeu de go (pour ne citer que ceux­là) font appel de manière très fréquente à des heuristiques qui modélisent l'expérience d'un joueur. Certains logiciels antivirus se basent également sur des heuristiques pour reconnaître des virus informatiques non répertoriés dans leur base, en s'appuyant sur des ressemblances avec des virus connus.

? Applications 

? Cryptologie    et compression de données ? Structure de données   , Algorithmes de tri et Recherche dichotomique ? Allocation de mémoire    et ramasse­miettes ? Informatique musicale    ? Algorithme génétique    en informatique décisionnelle 

? Voir aussi 

? Al­Khuwarizmi    ? Algorithme récursif    ? Algorithme réparti    ? Liste des algorithmes    ? Métaheuristique    ? Recherche opérationnelle    ? Structure de contrôle    

? Liens externes 

? Wikilivres    Les Wikilivres sont une source d'information Wiki pour les langages de programmations et l'algorithmique ? Eléments d'Algorithmique    Tout un livre sur l'algorithmique, gratuit en PDF. ? Cours et exercices d'algorithmique    L'entraînement de l'équipe de France aux Olympiades Internationales d'Informatique. ? Cours d'initiation à l'algorithmique    ? Introduction à l'algorithmique   , avec des exemples en langage C 

? Initiation à l'algorithmique    

λ 2. CodageDe façon générale un codage permet de passer d'une représentation des données vers une autre.

Parmi les différents codages utilisés, on trouve :

λ Le codage de Huffman, qui permet de faire de la compression de données (essentiellement sur du texte). λ Le codage de caractères pour représenter les textes dans diverses langues. λ La transformation d'une source vidéo ou sonore en un format informatique déterminé. Coder en MP3, en AVI, etc. Dans ce cas, le codage n'est plus une opération mathématique bijective (réversible) et l'expression encodage numérique est utilisée. Cette expression, peu rigoureuse, s'est répandue dans le milieu informatique sous l'influence de l'anglais encoding; en bon français on parlera de codage numérique. 

λ Il faut remarquer que dans un ordinateur tout est programmé en binaire c’est­à­dire à partir de 1 et de 0. Il existe une méthode qui permet de passer d'un en base 10 (1,2,3,4,5,6,7,8,9) en remarquant par exemple que 9=1*2^3+0*2^2+0*2^1+1*2^0 ainsi le codage binaire de 9 est 1001 

Le codage fait appel à des codec (CODeur/DECodeur) s'appuyant sur des algorithmes afin de compresser une source pleine en une forme plus légère, mais toujours exploitable lors du décodage, par ces mêmes codecs.

λ 3.Contrôle de version

λ Gestion de version

La gestion de version (en anglais revision control) est une activité qui consiste à maintenir l'ensemble des versions d'un logiciel. Essentiellement utilisée dans le domaine de la création de logiciels, elle est surtout concernée par le code source ; mais elle peut être utilisée pour tout type de document informatique.

Cette activité étant fastidieuse et relativement complexe, un appui logiciel est presque indispensable.  ﾀ cet effet, il existe différents logiciels de gestion de version qui, bien qu'ayant des concepts 

essentiels communs, apportent chacun son propre vocabulaire et ses propres usages.   ﾀ titre d'exemple, on trouve un mécanisme de gestion de version dans Wikipedia : pour chaque article, l'historique est disponible en cliquant sur le lien Historique.

Sommaire

1 Les versions 2 Modifications et ensemble de modifications 3 Branches 

3.1 Conflit de modifications 4 Systèmes centralisés et décentralisés 5 Fonctionnalités notoires des logiciels de gestion de version 

5.1 Etiquetage ou marquage 

5.2 Comparaison 

1 Les versions 

Les logiciels évoluant, chaque étape d'avancement est appelée version. Les différentes versions sont nécessairement liées à travers des modifications.

Une modification peut correspondre à des ajouts, modifications, suppressions ou une combinaison des trois sur une version donnée. Schématiquement, on passera de la version N à la version N + 1 en appliquant une modification M. Un logiciel de gestion de versions nous aidera alors à soustraire la modification M à la version N + 1 pour retrouver la version N.

Il est à noter que les concepteurs du logiciel de gestion de versions CVS ont choisi de parler de ｫ révisions   ｻ (revisions) afin de ne pas confondre la version du logiciel avec les ｫ révisions   ｻ de ses fichiers sources.

Pour des raisons pratiques, on associe généralement un ｫ numéro   ｻ à une version (voir Version d'un logiciel).

? 2. Modifications et ensemble de modifications 

Une modification constitue donc l'évolution entre deux versions. On peut donc aussi bien parler de la différence entre deux versions que de modification ayant amené à une nouvelle version.

On utilise généralement la gestion de version à un ensemble de fichiers qui constitue un projet. De ce fait, il est courant de parler de modification pour un seul fichier et d'ensemble de modifications (change set) lorsqu'il s'agit du projet (et donc de plusieurs fichiers). En effet, les deux n'évoluent pas au même rythme.

Pour illustrer, prenons l'exemple d'un logiciel nommé ｫ Toto ｻ. Il est constitué des fichiers A, B et C.   ﾀ la version 1.0 de ｫ Toto   ｻ correspondent les versions 1.0 de chacun des fichiers. Admettons que l'ajout d'une fonctionnalité à ｫ Toto   ｻ impose la modification de A et de C. Présentons la situation à l'aide d'un tableau

versions de ｫ Toto ｻ versions de A versions de B versions de C1.0 1.0 1.0 1.01.1 1.1 1.1

Du point de vue du projet, les modifications apportées à A et à C font partie du même ensemble.

? 3. Branches 

Des modifications divergentes peuvent intervenir sur un ensemble de fichiers. On parle alors de branches. Parfois il s'agit aussi de faire converger des branches. On parle alors de fusion de branches.

Les branches sont utilisées pour permettre :

• la maintenance d'anciennes versions du logiciel (sur les branches) tout en continuant le développement des futures versions (sur le tronc) ; 

• le développement parallèle de plusieurs fonctionnalités volumineuses sans bloquer le travail quotidien sur les autres fonctionnalités. 

Conflit de modifications

Dans le cas d'une gestion de version en équipe, chacun travaille de façon indépendante, donc sur des branches de versions différentes. Les fusions régulières sont nécessaires à un avancement global du logiciel.

Il n'est pas rare que, suite à une mauvaise communication au sein de l'équipe, certaines modifications soient contradictoires (par exemple lorsque deux personnes ont apporté des modifications différentes à la même partie d'un fichier). On parle alors de conflit (de modifications) puisque le logiciel de gestion de version n'est pas en mesure de savoir laquelle des deux modifications appliquer.

? 4.Systèmes centralisés et décentralisés CVS et Subversion sont des logiciels centralisés, ce qui veut dire qu'il n'existe qu'un seul dépôt des fichiers, dépôt qui fait référence. Cela peut simplifier le modèle mais cela est contraignant pour certains usages (travail sans connexion au réseau ou tout simplement travail sur des branches expérimentales ou bien contestées).

Il existe donc également des logiciels décentralisés comme Mercurial ou darcs. Avec ceux­ci, il existe plusieurs dépôts dont aucun n'a de statut privilégié.

? 5.Fonctionnalités notoires des logiciels de gestion de version 

? Etiquetage ou marquage 

Cela consiste à associer un nom à une version donnée. Pour certains outils de gestion de version (comme CVS) qui gèrent les versions à une faible granularité (beaucoup de modification non significatives), c'est un moyen de retrouver facilement une version significative.

Comparaison 

Il est possible de comparer plusieurs versions pour en extraire les modifications.

Verrouillage et notifications 

Pour le travail en équipe, certains logiciels de gestion de version apportent des outils pour communiquer.

Par exemple, le verrouillage permet d'interdire la modification d'un fichier, tandis que la notification émet un avertissement à tous les autres membres lorsqu'un fichier est modifié.

? Exemples de logiciels de gestion de version Les logiciels de contrôle de version sont nombreux. Sous UNIX il y a eu SCCS qui a suscité un logiciel libre alternatif : RCS (Revision Control System) qui est devenu un standard de fait. Comme RCS ne gérait que des fichiers individuels, nombre de ses utilisateurs ont créé des surcouches gérant les arborescences de fichiers. Certaines de ces surcouches furent distribuées librement. Il en fut 

ainsi de PRCS et de CVS. CVS est devenu extrêmement répandu dans le monde du logiciel libre sur Internet, mais aussi dans les entreprises. CVS est simple à mettre en ?uvre et offre les fonctionnalités fondamentales qu'attendent ses utilisateurs.

Mais l'histoire des logiciels de contrôle de version ne s'arrête pas en 2006 et de nouveaux logiciels libres concurrencent CVS, comme par exemple Subversion, SVK, darcs, mercurial et GNU Arch.

Dans le monde propriétaire, ClearCase (de IBM), Synergy/CM (de Telelogic) et Serena Dimensions (de Serena) sont les plus répandus. Visual Source Safe (de Microsoft) est largement utilisé aussi, notamment du fait de son intégration avec l'outil de développement Visual Studio, malgré de nombreuses lacunes et des mises à jour peu fréquentes. En 2006 Microsoft lance une nouvelle famille d'outils de développement et de Gestion de configuration logicielle sous le nom de Team Suite et Team Foundation Server. Cette suite qui s'appuie sur Visual Studio 2005 intègre entre autres un nouveau logiciel de gestion de version plus complet et ambitieux que Visual Source Safe.

? Voir aussi 

? Logiciel de gestion de versions    ? Gestion de configuration    ? Version d'un logiciel    ? Gestion de version décentralisée    

? 4.  Refactorisation

La refactorisation (anglicisme venant de refactoring) est une opération de maintenance du code informatique. Elle consiste à retravailler le code source non pas pour ajouter une fonctionnalité supplémentaire au logiciel mais pour améliorer sa lisibilité, simplifier sa maintenance, ou changer sa généricité (on parle aussi de remaniement). Une traduction plus appropriée serait réusinage. C'est donc une technique qui s'approche de l'optimisation du code, même si les objectifs sont radicalement différents.

1. Sommaire

? 1 Pourquoi refactoriser      ?   ? 2 Les niveaux de refactorisation    

? 2.1 Modification de la présentation    ? 2.2 Modification de l'algorithmique    ? 2.3 Relocalisation de procédures    ? 2.4 Refonte du design    

? 3 Des activités de refactorisation    ? 3.1 Suppression du code mort    ? 3.2 Ajout d'assertions    ? 3.3 Renommage    ? 3.4 Commentaires    

? 4 Référence   s   

Au fur et à mesure de la vie d'un logiciel on est amené à implémenter de nouvelles fonctions ou à corriger des bugs. Or ces modifications ne s'imbriquent pas toujours avec élégance dans l'architecture du logiciel.

Le code source d'un programme tend donc à devenir de plus en plus complexe au fur et à mesure de son existence.

Cela est notamment vrai avec les techniques modernes de développement itératif incrémental où le logiciel entre en phase de modification pratiquement dès le début de son existence.

Il est donc important de mettre en ?uvre des techniques qui permettront de toujours conserver un code aussi simple que possible. Cela consiste à :

• S'assurer que toute l'information nécessaire est disponible • Supprimer toute information redondante ou duplication de code • Simplifier l'algorithmique des méthodes • Limiter la complexité des classes • Limiter le nombre de classes 

2. Les niveaux de refactorisation 

On peut distinguer plusieurs niveaux de refactorisation, selon l'impact des modifications sur le déroulement du programme et les risques rencontrés. En pratique, durant une même session de refactorisation on jonglera souvent entre ces divers niveaux.

Modification de la présentation 

A ce niveau on cherche à simplement améliorer la présentation du code source sans modifier le code exécuté. Ce type d'amélioration concerne donc essentiellement les commentaires (suppression des commentaires superflus, ou ajout de commentaires sur des sections complexes) et la mise en page (indentation du code, passages à la ligne).

Modification de l'algorithmique 

Ce type de modification est destiné à conserver des méthodes aussi simples que possible. Cela est le plus souvent réalisé en scindant une méthode ou un algorithme en plusieurs parties ou en confiant à un objet annexe une partie du traitement.

Dans ce type de modification, il est tout à fait possible (et fréquent) d'introduire des bugs, il est donc fortement conseillé de construire une batterie de tests unitaires et de l'exécuter après chaque modification.

Relocalisation de procédures 

C'est un cas particulier de la modification de l'algorithmique. Cela consiste à déplacer une procédure dans une autre procédure ou dans le corps principal de la classe. (à compléter).

Refonte du design 

C'est le type de modification le plus radical puisqu'il consiste à modifier la hiérarchie de classes composant l'application. Il est là aussi préférable de procéder par petites modifications et d'exécuter une suite de tests à chaque fois. Il est par ailleurs très difficile de réaliser une refonte en profondeur sans outil spécialisé comme un explorateur de classes.

3.Des activités de refactorisation 

Suppression du code mort 

Le code mort est du code qui ne sert à rien car il n'est jamais appelé par une autre partie du programme. Il ne sert donc qu'à rendre le code source plus complexe et à provoquer des risques de confusion.

Le plus difficile est bien entendu de détecter le code mort, on peut pour cela utiliser plusieurs techniques:

• recherche statique par l'outil grep sur le code source pour vérifier qu'une méthode est bien appelée quelque part 

• analyseur de références croisées (par exemple l'outil objxref livré avec le compilateur turbo C de Borland) 

• outil de mesure de couverture de code. C'est sans doute la méthode la plus pratique puisqu'elle permet également de vérifier des portions de méthodes. Elle est également la plus risquée puisque du code peut être marqué comme non couvert simplement parce que votre suite de test n'est pas complète (ce qui est en pratique toujours le cas). 

Il existe une autre forme de code mort: le code commenté. Il arrive souvent que suite à des modifications, on laisse des pans entiers de l'ancien code pour pouvoir éventuellement revenir à la version antérieure facilement. Ce type de code devrait également être supprimé à la fin de la session de développement.

Dans tous les cas, il n'est jamais recommandé de conserver du code qui pourrait servir un jour. Il est toujours préférable de le supprimer de la version de travail et d'utiliser un outil de contrôle de version pour archiver ce type de code.

Ajout d'assertions 

Les assertions sont une technique de programmation qui consiste à vérifier qu'un certain nombre de conditions sont vérifiées. Elles sont très intéressantes d'une part car elles permettent de simplifier le déboggage en détectant les erreurs au plus tôt, mais également parce qu'elles sont placées à l'intérieur du code qu'elles contrôlent et peuvent donc aider à la compréhension de l'état du système.

Renommage

Au fur et à mesure du développement d'un logiciel, le rôle des classes et des méthodes devient plus 

clair. Il est donc souvent utile de modifier les noms de classes ou de méthodes pour bien indiquer ce rôle.

Commentaires 

Les commentaires sont un sujet assez controversé de documentation du logiciel. Il est de toute façon important de toujours garder les commentaires synchronisés avec le code.

? Références ? Jean­Philippe Retaillé, Refactoring des applications Java/J2EE, Eyrolles, 2005, 390 p., ISBN 2212115776 ? Martin Fowler, Kent Beck, Refactoring: Improving the Design of Existing Code, Addison­Wesley Professional, 1999, 464 p., ISBN 0201485672 

? Joshua Kerievsky, Refactoring to Patterns, Addison­Wesley Professional, 2004, 400 p., 

ISBN 0321213351 

5. Test unitaire

En programmation, le test unitaire est un procédé permettant de s'assurer du fonctionnement correct d'une partie déterminée d'un logiciel ou d'une portion d'un programme.

Il s'agit pour le programmeur de tester un module, indépendamment du reste du programme, ceci afin de s'assurer qu'il répond aux spécifications fonctionnelles et qu'il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne couramment d'une vérification de la couverture de code, qui consiste à s'assurer que le test conduit à exécuter l'ensemble (ou une fraction déterminée) des instructions présentes dans le code à tester. L'ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de régressions (l'apparition de nouveaux dysfonctionnements).

Dans les applications non critiques, l'écriture des tests unitaires a longtemps été considérée comme une tâche secondaire. Cependant, la méthode Extreme programming (XP) a remis les tests unitaires, qu'elle nomme maintenant Tests du Programmeur, au centre de l'activité de programmation.

La méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester (TDD). Ceci permet de définir précisément l'interface du module à développer. En cas de découverte d'un bogue logiciel, on écrit la procédure de test qui reproduit le bogue. Après correction on relance le test, qui ne doit indiquer aucune erreur.

6. Optimisation de code

En programmation informatique, l'optimisation est la pratique qui consiste généralement à réduire le temps d'exécution d'une fonction, l'espace occupé par les données et le programme, ou la consommation d'énergie.

La règle numéro un de l'optimisation est qu'elle ne doit intervenir qu'une fois que le programme fonctionne et répond aux spécifications fonctionnelles. L'expérience montre qu'optimiser du code avant que ces deux conditions ne soient réalisées revient le plus souvent à une perte de temps et s'avère néfaste à la clarté du code et au bon fonctionnement du programme :

ｫ L'optimisation prématurée est la source de tous les maux. ｻ, Donald Knuth citant Dijkstra 

La plupart des compilateurs récents pratiquent de façon automatique un certain nombre d'optimisations qu'il serait fastidieux d'effectuer manuellement et qui rendraient le code source moins lisible.

L'optimisation manuelle peut s'avérer nécessaire dans des cas très spécifiques, mais les mesures montrent que sur des machines RISC qui possèdent un nombre élevé de registres et où l'efficacité demande le regroupement des instructions identiques pour bénéficier de l'effet pipeline, l'optimiseur d'un compilateur C fournit souvent un code plus efficace que celui qui serait écrit en assembleur par un programmeur expérimenté (ce qui n'était jamais le cas sur les machines CISC). Et de surcroit ce code est bien plus facile à maintenir, car les instructions en C restent dans un ordre lié à la seule intelligibilité du code et non aux spécificités de la machine : dans les optimiseurs actuels, en effet, les ordres machines associés à une instruction ne se trouvent plus nécessairement en position contiguë, pour des raisons d'efficacité d'exécution. Cela rend le code assembleur généré particulièrement indéchiffrable.

1. Sommaire

? 1 Pratique de l'optimisation    ? 1.1 Première approche    ? 1.2 Seconde approche    

? 2 Optimisation automatique    ? 2.1 Exemples    

? 2.1.1 Une spécificité du binaire      : le    décalage ? 2.1.2 Le mot clef inline du C    

?

? 1. Pratique de l'optimisation 

? Première approche 

Avant de commencer l'optimisation, il faut savoir mesurer la vitesse du code. Pour cela il faut choisir un paramètre, de préférence simple, mesurable. Ceci peut­être par exemple le temps de traitement sur un jeu de donnée précis, ou le nombre d'images affichées par seconde, ou encore le nombre de requêtes traitées par minute.

Une fois le paramètre de mesure déterminé, il faut mesurer le temps passé dans chacune des parties du programme. Il n'est pas rare que 80% à 90% du temps soit consacré à l'exécution de 10% du code (les boucles critiques). Les chiffres varient en fonction de la taille et de la complexité des projets. Il faut localiser ces 10% de code pour être le plus rentable dans ses optimisations. Cette étape de localisation peut être réalisée à l'aide d'outils spécialisés d'instrumentation du code nommés profilers. Ils sont chargés de compter le nombre d'exécutions de chaque fonction et de cycles du microprocesseur correspondants au cours de l'exécution.

Ensuite on itère sur la section la plus consommatrice de ressource autant de fois que nécessaire cette boucle :

• optimisation d'une partie du code • mesure du gain de performances 

Seconde approche 

On peut optimiser à plusieurs niveaux un programme:

• au niveau algorithmique, en choisissant un algorithme de complexité inférieure (au sens mathématique) et des structures de données adaptées, 

• au niveau du langage de développement, en ordonnant au mieux les instructions et en utilisant les bibliothèques disponibles, 

• en utilisant localement un langage de bas niveau, qui peut être le langage C ou, pour les besoins les plus critiques, le langage assembleur. 

On ne passe au niveau supérieur d'optimisation qu'une fois qu'on a épuisé les possibilités d'un niveau. L'utilisation d'un langage de bas niveau sur l'ensemble d'un projet pour des raisons de rapidité est l'une des erreurs les plus communes et les plus coûteuses que puisse faire un projet industriel.

L'optimisation de code est considéré par beaucoup de développeurs amateurs comme un art un peu magique et, pour cette raison, comme l'une des parties les plus excitantes de la programmation. Ceci les conduit à croire qu'un bon programmeur est une personne qui optimise d'emblée le programme. Cependant l'expérience montre qu'elle ne peut palier une mauvaise conception initiale. C'est dans la  conception que l'expérience du développeur joue le plus. Par ailleurs, dans un nombre majoritaire et grandissant de cas, le ｫ bon programmeur   ｻ est moins celui qui écrit du code astucieux (l'optimiseur s'en chargera le plus souvent mieux que lui) que celui qui écrit du code lisible et aisé à maintenir.

Une bonne connaissance des techniques de structures de données ainsi que des algorithmes (même sans aller jusqu'aux considérations théoriques poussées de la complexité algorithmique) se montre bien plus féconde que celle d'un langage d'assemblage. Lorsqu'on a déterminé l'algorithme le plus adéquat, les optimisations les plus efficaces peuvent être obtenues en utilisant le chemin suivant :

• écriture du code critique dans un langage de haut niveau (comme Scheme ou Common Lisp), 

• application de transformations mathématiques successives qui préservent la spécification du programme tout en réduisant la consommation des ressources, 

• traduction du code transformé dans un langage de bas niveau (langage C). 

Dans la pratique, les performances des machines actuelles font que des applications comportant beaucoup d'entrées­sorties peuvent faire l'économie de ces trois étapes et se rédiger directement dans un langage comme Haskell. L'application bien connue nget, qui moissonne systématiquement les images publiées dans les forums Usenet, avait dans sa première implémentation été écrite en Haskell. La version en C n'en a été qu'une traduction qui ne se révèle pas plus performante pour ce type d'application.

? Optimisation automatique 

Les compilateurs sont souvent capable de faire des optimisations locales, auxquelles aucun développeur ne penserait en première approche.

Pour le langage C, cela peut considérer :

• les variables locales et les registres 

• les fonctions non implémentées en assembleur en tant que fonction • les switch, qui sont optimum. 

• Exemples 

• Une spécificité du binaire : le décalage 

Une des toutes premières optimisations a été celle de la division et de la multiplication par une puissance de 2.

En effet, l'informatique actuelle repose sur le binaire, puisqu'elle utilise comme élément de base le transistor (et historiquement, auparavant le relais) qui n'autorise que deux valeurs différentes.

On a donc logiquement implémenté en langage machine les opérations de décalage à gauche et décalage à droite.

En effet, en binaire, le décalage d'un nombre d'un cran vers la gauche le multiplie par 2.

Ainsi, 2 (102) décalé de 1 bit donne 4 (1002). 

5 (1012) décalé de 2 bits donne 20 (101002) : 5 * 22 = 20. 

Ceci marche aussi pour la division, en décalant les bits vers la droite.

100 (11001002) décalé de 3 bits vers la droite donne 100 / 23 = 12.5 donc 12 (11002) car nous travaillons sur des nombres entiers. 

La division (en dehors de ce cas et des cas pathologiques) est une instruction coûteuse en temps machine, et n'est d'ailleurs toujours pas disponible sur la grande majorité des processeurs de type RISC.

λ Le mot clef inline du C 

Le code C suivant:

inline int f(int a, int b) {    return a * b;}

int g (int a) {    switch (a) {        case 10:            return f(a, a);        case 11:         case 12:            return f(a ­ 2, a);        case 1200:            return f(a ­ 2, a);        default:            return f(a, a);    }}

Une compilation avec gcc ­O4 ­S donne:        .file    "opt.c"        .text        .p2align 4,,15        .globl   g        .type    g, @functiong:        pushl   %ebp        movl    %esp, %ebp        movl    8(%ebp), %edx        cmpl    $12, %edx        jg      .L14        leal    ­2(%edx), %eax        cmpl    $11, %edx        jge     .L15        movl    $100, %eax        cmpl    $10, %edx.L17:        je      .L2        movl    %edx, %eax.L15:        imull   %edx, %eax.L2:        popl    %ebp        ret        .p2align 4,,7.L14:        movl    $1437600, %eax        cmpl    $1200, %edx        jmp     .L17        .size   g, .­g        .section        .note.GNU­stack,"",@progbits        .ident  "GCC: (GNU) 3.3.2 (Mandrake Linux 10.0 3.3.2­6mdk)"

Ce qui pourrait se traduire, pour une compréhension plus aisée, par le code C suivant:int g(int a) {

 int eax, b;

 if (a > 12)          /* cas a == 1200 */   goto L14;

 eax = a ­ 2; if (a >= 11)         /* cas a == 11 ou a == 12 */   goto L15;

 eax=100;             /* = 10 * 10 */ b=10;

L17: if (a == b)          /* cas a == 10 */   goto L2;                      /* cas "default" */ eax=a;L15: eax=eax*a; L2: return eax;

L14:

 eax = 1437600;       /* = 1200*(1200­2) */ b = 1200; goto L17;}

On peut remarquer par exemple que la fonction 'f' n'a pas été générée, mais que son code a directement été incorporé dans la fonction 'g' (le mot clef 'inline' permet de forcer ce type d'optimisation en C )

? Voir aussi ? Evaluation paresseuse    ? Interprétation abstraite    ? Low Level Virtual Machine    ? Mémoire cache    ? Mémoization    ? Principe de localité    ? Simulation de phénomènes    

? Théorie des files d'attente    

6. Packaging

Le packaging est l'anglicisme pour conditionnement.

Le conditionnement est constitué de plusieurs éléments appelés composants d'emballage. Il peut être défini de différents points de vue : Industriel (protéger le produit contenu), logistique (transporter et identifier), laboratoire (garder intactes les propriétés du contenu), marketing (passer le message/la promesse), design/agence de création (ajouter de la valeur au produit), service légal (porter les mentions/logotypes obligatoires très stricts), Commercial (augmenter/faciliter la vente) etc. Le conditionnement a pour fonction première de protéger le contenu et doit avoir des qualités chimiques particulières pour garantir le produit tout au long de la chaîne de distribution. Il est réalisé des tests de compatibilité en étuve pour vérifier le couple emballage/produits.

Il y a plusieurs niveaux d’emballages.

­ L’emballage primaire est celui qui est en contact avec le contenu, poudre, liquide, solide... C’est souvent l’unité de vente consommateur (UVC). Celui qui sera éliminé par le consommateur.

­ L’emballage secondaire permettra de rassembler les UVC pour les amener jusqu’aux rayons des magasins. Par exemple : Caisse américaine. Il sera recyclé par le distributeur.

­ L’emballage tertiaire ou packaging logistique qui permettra de transporter les produits en magasins ou chez l’industriel. Ce sont par exemple les palettes, films, étiquettes d’identification, coiffes, cornières, etc.

Les emballages primaires les plus courants : ­ Flacons/bouteilles/pots en plastique (polypropylène 

PP, polyéthylène haute densité), verre (coloré, blanc), aluminium, acier (fer blanc) ­ Bouchages en polypropylène, acier, pompes distributrices (crèmes ou spray), push­pull... ­ Sachets 4 ou 3 soudures (ex : sucre en poudre) en matériaux complexés (PA/PE, PET/PA/PE...), films flowpack... ­ Barquette PS avec film étirable ou soudé

Les emballages secondaires les plus courants : ­ ﾉ tuis carton à ouverture facile ou à rabats... ­ Coffrets ou flow­pack (film plastique) permettant le regroupement lors de promotions.

Les emballages tertiaires : ­ Caisses de transport (caisse américaine), palettes, films rétractés, étiquettes logistique, etc.

Divers :

• Le coût d’un emballage peut représenter de 10% à 50% du coût total d’un produit. • Trois pays dans le monde forment des ingénieurs packaging : Allemagne, ﾉ tats­unis et 

France. 

Le packaging est constitué de l'emballage et du conditionnement d'un produit industriel.

En France, on considère que le packaging se réfère davantage à l'apparence, confiée à un designer. Il permet la reconnaissance du produit en le rendant plus visible et attrayant dans les lieux de distribution (supermarchés ou petits magasins). Les produits de consommation se vendent majoritairement dans des magasins en libre­service dans lesquels ils doivent se vendre seuls. L'expérience a montré que, de deux produits dont la valeur d'usage est similaire, c'est celui dont l'aspect extérieur et/ou le packaging a été le mieux étudié qui se vendra le mieux. Aussi, aujourd'hui, le design du produit et son packaging font partie intégrante de l'étude du produit lui­même. Son objectif est généralement d'augmenter les ventes et la valeur de ce produit en lui attribuant des caractéristiques et/ou des valeurs.Le packaging est un espace de communication gratuit permettant de valoriser un produit qui se trouve au milieu de ses concurrents dans les linéaires des grandes surfaces.

Le packaging a une valeur de signalisation, à la façon d'un panneau STOP pour la reconnaissance ou la curiosité. Il est une référence : couleur, forme, format qui révèle le contenu. Il donne des informations : composition, mode d'emploi, limites de consommation, dangers. Il est utilitaire : ergonomie, stockage adéquat. Il s'attache à un positionnement. Le packaging d'un produit est élaboré en fonction du type des consommateurs ciblés. Il évoque une gamme de prix.

En anglais le packaging désigne l'ensemble des caractéristiques d'un emballage, pas uniquement son apparence.

CHAPITRE VI.  MODELISATION

?  1. Méthodes de modélisation 

Une méthode d'analyse et de conception a pour objectif de permettre de formaliser les étapes préliminaires du développement d'un système afin de rendre ce développement plus fidèle aux besoins du client. Parmi les méthodes les plus connues on peut notamment citer Merise, RAD et SADT

2. Méthodes de développement (Gestion de projet) 

λ Méthode agile    λ Extreme programming    (XP) 

λ Dynamic systems development method    (DSDM) λ Adaptive software development    (ASD) λ Scrum    λ Feature driven development    λ Crystal clear    

λ Merise    

λ 3. Langages de modélisation 

λ UML    λ BON    

λ Merise    

λ 4. Approche objet 

λ Orienté objet    λ Interface de classe    

λ 5. Les écueils classiques 

λ la balle en argent    λ prototypage    λ le plaqué or 

λ la loi de Brooks 

λ 6. Liens externes λ Article Le processus unifié un processus de développement logiciel itératif 

? Autres langues

? English    

CHAPITRE VII. BASE DE DONNÉES

Une base de données, usuellement abrégée en BD ou BDD, est un ensemble structuré et organisé permettant le stockage de grandes quantités d'informations afin d'en faciliter l'exploitation (ajout, mise à jour, recherche de données).

Une base de données se traduit physiquement par un ensemble de fichiers présent sur une mémoire de masse (bien souvent un disque). Certaines peuvent être accessibles via les réseaux, on parle alors de base de données en ligne.

Il existe plusieurs types de bases :

1. Sommaire

? 1 Structure    ? 1.1 Bases de données hiérarchiques    ? 1.2 Bases de données réseaux    ? 1.3 Bases de données relationnelles    ? 1.4 Bases de données orientées    objet ? 1.5 Bases de données semi­   structurées ? 1.6 Bases de données    multidimensionnelles ? 1.7 Bases de données XML natives    

? 2 Schématisation de cette structure      : le    schéma conceptuel ? 3 Contenu et utilisation    

? 3.1 Bases de données multimédia    ? 3.2 Bases de données    décisionnelles ? 3.3 Bases de données    géographiques (SIG) ? 3.4 Bases de données factuelles    

? 4 Voir aussi    ? 4.1 Article connexe    ? 4.2 Liens externes    

? 1. Structure Le point le plus important pour pouvoir considérer un logiciel comme une base de données est son processus aux accès concurrent aux données/enregistrements. Ce point est primordial pour permettre le développement durable, sécuritaire, réparti et efficace d'une base de données.

1.1 Bases de données hiérarchiques 

 

Le premier système de base de données a été conçu pour la gestion des données du programme Apollo de la NASA. Les données étaient structurées dans des hiérarchies, comparables à l'organisation des répertoires sur un PC. Mais certains problèmes de stockage ont mené à utiliser (et donc à inventer) des bases de données de type réseaux. Les fichiers XML sont une réminiscence moderne des bases hiérarchiques et il existe donc des bases de données XML natives.

1.2 Bases de données réseaux 

Voir aussi l'article Base de données réseau. 

Ce modèle de base de données a été inventé par Charles.W. Bachman. Pour son modèle, il reçut en 1973 le prix Turing.

1.3 Bases de données relationnelles 

Voir aussi l'article Base de données relationnelle. 

En 1970, au moment où les systèmes reposant sur le modèle hiérarchique ou le modèle en réseau étaient en plein développement, Edgar Frank Codd publia un article où il proposait de stocker des données hétérogènes dans des tables, permettant d'établir des relations entre elles. De nos jours, ce modèle est extrêmement répandu, mais en 1970, cette idée était considérée comme une curiosité intellectuelle. On doutait alors que les tables puissent être jamais gérées de manière efficace par un ordinateur. Ce scepticisme n'a cependant pas empêché E.F. Codd de poursuivre ses recherches. Un premier prototype de Système de gestion de bases de données relationnelles (SGBDR) est construit dans les laboratoires d'IBM. Depuis les années 1980, cette technologie a mûri et a été adoptée par l'industrie. En 1987, le langage SQL, une extension de l'algèbre relationnelle, est standardisé. ? l'heure actuelle, les SGBDR sont présents dans de nombreux logiciels, sont très répandus dans les bases de données et représentent une industrie de plusieurs milliards de dollars.

1.4 Bases de données orientées objet 

Voir aussi l'article Base de données orientée objet. 

Les exemples les plus connus à l'heure actuelle de base de données orientées objets sont les annuaires, qui sont capables de stocker une multitude d'informations. Ils la stockent dans des objets, très souvent une fiche individuelle, une machine, une ressource... à laquelle on associe des valeurs, ses attributs.

1.5 Bases de données semi­structurées 

1.6 Bases de données multidimensionnelles 

Elles permettent de stocker différentes données numériques aux croisements des "n" axes correspondant aux "n" dimensions de la base.

Il est alors possible de naviguer dans cet espace, à différents niveaux d'agrégats (zooms, rotation d'axes, etc.) : ces bases de données sont appelées cubes ou hypercubes en informatique décisionnelle et sont souvent utilisés dans les métiers du contrôle de gestion.

1.7 Bases de données XML natives Voir aussi l'article Base XML native. 

Ces bases de données s'appuient sur la structure offerte par le langage XML pour stocker les données et les repérer.

Elles représentent une évolution importante du concept de base de données permettant de stocker des volumes importants de données ou de documents, y compris multimédia.

L'organisation des données dans le langage XML reste cependant hiérarchique.

? 2.Schématisation de cette structure : le schéma conceptuel Voir aussi l'article Schéma conceptuel. 

? 3. Contenu et utilisation 

? 3.1 Bases de données multimédia Voir aussi l'article Base de données multimédia. 

3.2 Bases de données décisionnelles Voir aussi l'article Informatique décisionnelle. 

Les bases de données décisionnelles sont utilisées en lecture intensive, dans le cadre de l'aide à la décision. Leur contenu provient de l'ensemble des bases de données de production (RH, gestion des stocks, gestion commerciale, gestion de la production, marketing, etc.) par scripts et batchs, ou bien par des outils de type ETL, EAI ou ESB.

Les datawarehouse et datamart sont des exemples de bases relationnelles utilisées de manière décisionnelle.

Les bases de données multidimensionnelles (cubes multidimensionnels) sont généralement utilisées de manière décisionnelle.

3.3 Bases de données géographiques (SIG) 

Voir aussi l'article Système d'information géographique (SIG). 

3.4 Bases de données factuelles 

Base de données regroupant des données établies et attestées concernant un domaine comme la chimie, la physique, la médecine, etc. Une base de données factuelles peut intégrer des données non textuelles comme des graphiques, des schémas... Dans ce cas, certains auteurs préfèrent parler de "banque de données".

Article connexe Les systèmes de gestion de base de données (ou SGBD) Langage d'interrogation de données Schéma conceptuel Dialog Pick (système d'exploitation) Table (base de données) 

Liens externes (fr) Applications des Bases de Données en Sciences Humaines et Sociales 

(fr) Introduction à la Conception des Bases de Données Relationnelles (fr) Introduction aux Bases de Données Multivalué (fr) base de données sur le comportement d'achat des ménages 

(fr) Politique de gestion des droits d'accès à une base de données 

CHAPITRE VIII: PROGRAMMATION ORIENTÉE OBJET

La programmation par objet (du terme anglo­saxon Object­Oriented Programming ou OOP), est un paradigme de programmation, il consiste en la définition et l'assemblage de briques logicielles appelées objets ; un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une personne ou encore une page d'un livre.

Orthogonalement à la programmation par objet, afin de faciliter le processus d'élaboration d'un programme, existent des méthodologies de développement logiciel objet dont la plus connue est USDP (Unified Software Development Process).

Il est possible de concevoir par objet une application informatique sans pour autant utiliser des outils dédiés. Il n'en demeure pas moins que ces derniers facilitent de beaucoup la conception, la maintenance, et la productivité. On en distingue plusieurs sortes :

• les langages de programmation (Eiffel, Python, C++, Smalltalk...) • les outils de modélisation qui permettent de concevoir sous forme de schémas semi­

formels la structure d'un programme (Objecteering, UMLDraw, Rapsody…) • les bus distribués (COM, CORBA, RMI, Pyro...) 

• les ateliers de génie logiciels (ou AGL) (Rational Rose XDE, Objecteering...) 

Des langages à objets, il en existe actuellement deux catégories : les langages à classes et ceux à prototypes, que ceux­ci soient sous forme fonctionnelle (CLOS, OCaml…) ou impérative (C++, Java…) ou les deux (Python).

1. Sommaire

? 1 Origines    ? 2 Les principes de bases    

? 2.1 L'objet (attribut et méthodes)    ? 2.2 Le typage et le    polymorphisme ? 2.3 La redéfinition    ? 2.4 Classe et prototype    

? 3 Le typage et la classification    ? 3.1 Le typage selon Liskov    ? 3.2 Le typage selon Cook    

? 4 Modélisation objet    ? 5 Sujets liés    ? 6 Bibliographie    

? 6.1 Lien externe    

? 1. Origines 

Le langage Simula­67 jette les prémisses de la programmation objet, résultat des travaux sur la mise au point de langages de simulation dans les années 1960 dont s'inspira aussi la recherche sur l’intelligence artificielle dans les années 1970­80. Mais c'est réellement par et avec Smalltalk 72 puis Smalltalk 80, inspiré en partie par Simula, que la programmation par objets débute et que sont posés les concepts de base de celle­ci : objet, messages, encapsulation, polymorphisme, héritage (sous­typage ou sous­classification), redéfinition, etc. Smalltalk est plus qu'un langage à objets, il est aussi un environnement graphique interactif complet.

? partir des années 1980, commence l'effervescence des langages à objets : Objective C (début des années 1980), C++ (C with classes) en 1983, Eiffel en 1984, Common lisp object system dans les années 1980, etc. Les années 1990 voient l'âge d'or de l'extension de la programmation par objet dans les différents secteurs du développement logiciel.

Depuis, la programmation par objet n'a cessé d'évoluer aussi bien dans son aspect théorique que pratique et différents ? métiers ? et ? discours mercatiques ? à son sujet ont vu le jour :

• l’analyse objet (AOO ou OOA en anglais), • la conception objet (COO ou OOD en anglais), • les banques de données objet (SGBDOO), • les langages objets avec les langages à prototypes, 

• ou encore la méthodologie avec MDA (Model Driven Architecture). 

Aujourd’hui, la programmation par objet est vue davantage comme un paradigme, le paradigme objet, que comme une simple technique de programmation. C'est pourquoi, lorsque l'on parle de nos jours de programmation par objets, on désigne avant tout la partie codage d’un modèle à objets obtenu par AOO et COO.

? 2. Les principes de bases 

? 2.1 L'objet (attribut et méthodes) 

Concrètement, un objet est une structure de données valuées et qui répond à un ensemble de messages. Cette structure de données définit son état tandis que l'ensemble des messages qu'il comprend décrit son comportement :

• Les données ou champs qui décrivent sa structure interne sont appelées ses attributs; • L'ensemble des messages forme ce que l'on appelle l'interface de l'objet ; • c'est seulement au travers de celui­ci que les objets interagissent entre eux. La réponse 

à la réception d'un message par un objet est appelée une méthode (méthode de mise en oeuvre du message) ; elle décrit comment est réalisé le message. 

Les attributs (ou plus exactement leur représentation informatique) et les méthodes sont cachés ; ils forment une boîte noire. C'est le principe d'encapsulation. Son avantage principal réside dans la capacité à pouvoir modifier la structure interne des objets ou les méthodes associées aux messages sans en impacter les utilisateurs des objets.

Exemple d'un objet représentant un nombre complexe donné. Celui­ci peut aussi bien être représenté sous forme cartésienne (réel, imaginaire) que sous forme trigonométrique ou exponentielle (module, angle). Cette représentation, quelle qu'elle soit, est cachée et est interne à l'objet sous forme d'une structure de données. Toutefois, celui­ci peut proposer deux messages permettant chacun de lire une représentation différente du nombre complexe. En utilisant les seuls messages que comprend notre nombre complexe, les objets appelants sont assurés de ne pas être impactés lors d'un changement de sa structure interne. Cette dernière n'est accessible que par (et donc aussi au travers) les méthodes des messages.

2.2 Le typage et le polymorphisme 

Dans la programmation par objet, chaque objet est typé. Le type définit la syntaxe (comment l'appeler ?) et la sémantique (qu'est ce qu'il fait ?) des messages auxquels peut répondre un objet. Il correspond donc, à peu de chose près, à l'interface de l'objet. Toutefois, la plupart des langages objets ne proposent que la définition syntaxique d'un type (C++, Java, C#, ...) et rares sont ceux qui fournissent aussi la possibilité de le définir sémantiquement (Eiffel avec sa conception par  contrats), pourtant nécessaire pour profiter au mieux des avantages de la conception objet.

Un objet peut appartenir à plus d'un type. C'est ce que l'on appelle le polymorphisme. Ceci permet d'utiliser des objets de types différents là où est attendue une valeur d'un type précis, dès que ceux­ci satisfont le type requis. Une façon de réaliser le polymorphisme est le sous­typage (appelé aussi héritage de type) : mécanisme par lequel est raffiné un type père en un autre type, le sous­type ; c'est un mécanisme de restrictions des espaces de valeurs du type. Les objets de ce sous­type sont conformes aussi au type père, ces objets sont donc d'au moins deux types. De ceci découle le principe de substitution de Liskov.

Exemples : soit un type Real = {plus: Real x Real ­> Real}et un sous­type Integer <: Real,soit r: Real et i: Integer, alors r plus i est valide.

On distingue dans les langages objets trois mécanismes du typage :

• le typage dynamique : le type des objets est implicite et déterminé à l’exécution lors de la création des dits objets (Smalltalk, CLOS, Python, PHP…), 

• le typage statique : le type des objets est spécifié explicitement par le développeur lors de leur déclaration (C++, Java, C#, Pascal…), 

• le typage par inférence : le type est déterminé par le compilateur ou par l'interpréteur à partir du contexte, de l'expression dans laquelle il apparait (OCaml). 

De même, deux mécanismes du sous­typage existent : l’héritage de type simple (Smalltalk, Java) et multiple (C++, Python, CLOS, Eiffel).

Attention : le polymorphisme n'est pas à confondre avec le sous­typage ou avec l’attachement dynamique (dynamic binding en anglais).

2.3 La redéfinition La programmation objet permet à un sous­type de raffiner la mise en ?uvre d'un message défini dans le type père, autrement dit de redéfinir la méthode associée au message : c'est le principe de redéfinition des messages (ou overriding en anglais).

Or, dans une définition stricte du typage (typage du premier ordre), l'opération résultant d'un appel de message doit être la même quel que soit le type exact de l'objet référé. Ceci signifie donc que, dans le cas où l'objet référé est de type exact un sous­type du type considéré dans l'appel, seule la méthode du type père est exécutée :Soit le type Reel = { plus: Reel x Reel ­> Reel}et son sous­type Entier <: Reel,alors si i: Entier et r: Reel, l'appeli plus rconduit à l'exécution de la méthode associée au message plus dans le type Reel, et non à celle associée au même message dans le sous­type Entier dans le cas d'une redéfinition.

Pour réaliser alors la redéfinition, deux solutions existent :

• le typage du premier ordre associé à l'attachement dynamique (c'est le cas de C++, Java, C#, ...). Cette solution induit une faiblesse dans le typage et peut conduire à des erreurs. Les relations entre type sont définies par le sous­typage (théorie de Liskov) ; 

• le typage du second ordre (duquel découle naturellement le polymorphisme et l'appel de la bonne méthode en fonction du type exact de l'objet). Ceci est possible avec Smalltalk et Eiffel. Les relations entre types sont définies par la sous­classification (théorie F­Bound de Cook). 

2.4 Classe et prototype 

La structure interne des objets et les messages auxquels ils répondent sont définis, explicités, par des modules logiciels. C'est aussi par ces mêmes modules que sont créés les objets, via des opérations dédiées. Deux représentations existent de ces modules : la classe et le prototype.

La classe est une structure informatique particulière dans le langage objet. Elle décrit la structure interne des données et elle définit les méthodes qui s'appliqueront aux objets de même famille (même classe) ou type. Elle propose des méthodes de création des objets dont la représentation sera donc celle donnée par la classe génératrice. Les objets sont dits alors instances de la classe. C'est pourquoi les attributs d'un objet sont aussi appelés variables d'instance et les messages opération d'instance ou encore méthodes d'instance. L'interface de la classe (l'ensemble des opérations visibles) forme les types des objets. Selon le langage de programmation, une classe est soit considérée comme une structure particulière du langage, soit elle même comme un objet (objet non­terminal). Dans ce dernier cas, la classe a besoin elle aussi d'être créée et définie par une classe : ce sont les méta­classes. L'introspection des objets ou la méta­programmation est définie alors dans ces méta­classes. Sinon, elle est définie dans le runtime au travers des objets ou des classes. La classe peut donc aussi être décrite par des attributs et des messages. Ces derniers sont alors appelés, par opposition aux attributs et messages d'un objet, variables de classe et opération ou méthodes de classe. Parmi les langages à classes on retrouve Smalltalk, C++, C#, Java, etc.

Le prototype est un objet à part entière et qui sert de prototype de définition de la structure interne et des messages. De ce prototype, par le mécanisme de clonage, sont créés les autres objets de mêmes types. Dans ce modèle, il n'y a plus de distinction entre attributs et messages : ce sont tous des slots. Un slot est un label de l'objet, privé ou public, auquel est attachée une définition : ce peut être une valeur ou une opération. Cet attachement peut être modifié à l'exécution. Chaque modification d'un slot est locale à l'objet concerné et n'impacte pas ses clones. Chaque ajout d'un slot impacte l'objet et l'ensemble de ses clones. Pour modifier globalement un slot, autrement dit 

pour impacter l'objet et tous ses clones, le concept de trait a été introduit. Un trait est un ensemble d'opérations de même catégorie (clonage, persistance, etc.) transverse aux objets. Il peut­être représenté soit comme une structure particulière du langage, comme un slot dédié ou encore comme un prototype. L'association d'un objet à un trait fait que l'objet et ses clones sont capables de répondre à toutes les opérations du trait. Un objet est toujours associé à au moins un trait, et les traits sont les parents des objets (selon une relation d'héritage). Un trait est donc un mixin doté d'une parenté. Parmi les langages à prototype on trouve Javascript, Self, Io, Slater, Lisaac, etc.

Voir l'article dédié : Programmation orientée prototype.

? 3. Le typage et la classification 

Dans la programmation par objet, chaque objet est d'un ou plusieurs types. Le mécanisme adopté par lequel un objet peut être de plusieurs types est le sous­typage. Il existe deux grandes théories sur le sous­typage. Celle, initiale, de Liskov et celle, plus actuelle, de Cook. Dans chacune, deux concepts sont définis : celui du typage et celui de classification.

3.1 Le typage selon Liskov 

Les types, dans la théorie des types de Liskov, et dont une définition sémantique a été donnée par Cardelli, sont dits types de premier ordre. Chaque objet est d'un type exact et ce type décrit syntaxiquement et sémantiquement les messages auxquels l'objet peut répondre. Ce type peut­être obtenu par sous­typage. L'objet est alors conforme à tous les types de l'arbre de raffinement (appelé aussi arbre d'héritage) d'un type de base jusqu'au type exact de l'objet. Dans cette approche, seule l'opération définie la première fois dans un type père est exécutée même si l'objet référant est d'un sous­type. Pour permettre la redéfinition, le mécanisme d'attachement dynamique est alors nécessaire. Dans le typage du premier ordre, les classes fournissent la représentation de la structure interne du type et les méthodes attachées à chaque message. Elles définissent une famille de mises en ?uvre du type. L'interface de la classe représente alors le type des instances de cette classe. C'est une relation 1 classe ­ 1 type et 1 type ­ plusieurs classes ; on a une dualité type/classe. Dans cette démarche, il existe au moins deux mécanismes d'héritage:

• le sous­typage ou l'héritage d'interface, et • la sous­classification ou l'héritage de mise en ?uvre. 

L’héritage est la faculté d’une sous­classe ou d’un sous­type d’hériter des propriétés de son parent et de les affiner. Le sous­typage est donc le processus par lequel on restreint l’espace des valeurs du type parent, et la sous­classification est le processus par lequel on récupère et on spécialise la mise en oeuvre (redéfinition).

Le typage du premier ordre inclut des langages comme Java, C++ ou encore C#. Certains langages objets tentent d'offrir une séparation entre le type et la classe (Objective­C et Java), tandis que d'autres mixent la classe avec le type qu'elle met en ?uvre (C++, Python).

3.2 Le typage selon Cook 

Toutefois, la théorie des types de Liskov se heurte au problème du sous­typage des types récursifs (les types avec au moins une opération qui accepte un objet de même type).

En effet :soit le type Nombre = {plus: Nombre x Nombre ­> Nombre},soit Reel <: Nombre.Selon le sous­typage du premier ordre, on aurait :Reel = {plus: Nombre x Nombre ­> Nombre}ou au mieux, avec la covariance simple :Reel = {plus: Nombre x Nombre ­> Reel}Or, mathématiquement, ceci est faux, et du point de vue objet implique une coercition, voire conduit à une erreur de typage ! Ce qui est correct c'est :Reel = {plus: Reel x Reel ­> Reel}. La covariance multiple permet de résoudre ce problème, toutefois, avec un typage de premier ordre, les types des arguments d'entrée du message plus ne peuvent pas être affinés mais seulement généralisés pour garder un typage correct.

La théorie des types de Cook (la théorie F­Bound) permet de résoudre ce problème en redéfinissant ce qu’est un type et ce qu’est une classe, ou plus exactement le sous­typage. Elle définit ce que l’on appelle le typage du second ordre.

Dans cette approche, les concepts de classe et de type ne sont plus distincts mais imbriqués. Une classe ne définit plus la mise en ?uvre d’un ou de plusieurs types. Si le type définit toujours l’interface des objets, la classe définit la mise en ?uvre d’une famille polymorphique finie et liée de types. Le type est devenu un élément d’une classe. L’accent n’est alors plus mis sur le sous­typage comme dans celle de Liskov, mais sur la sous­classification ; un héritage va décrire l’arborescence entre classes (et donc implicitement entre types). La sous­classification permet de restreindre l’espace des types.

Ainsi, selon cette théorie, une classe est un générateur de types et chaque type est généré en résolvant le paramètre d'entrée du générateur.

Ainsi, selon notre exemple précédent :Soit Classe_Nombre ( T <: Classe_Nombre(T) ) = { plus: T x T ­> T }Soit Classe_Reel tel que Classe_Reel <: Classe_Nombre.On a :Classe_Reel ( T <:Classe_Reel(T) ) = { plus: T x T ­> T, moins: T x T ­> T }.Soit Type_Reel = Classe_Reel(Type_Reel), Type_Reel est le point fixe de Classe_Reeld'où :Type_Reel = { plus: Reel x Reel ­> Reel, moins: Reel x Reel ­> Reel }On a aussi :Type_Reel < Class_Nombre( Type_Reel <: Classe_Nombre(Type_Reel) ) puisqueClasse_Reel <: Classe_Nombre, soit implicitementType_Reel <: Type_Nombre tel que Type_Nombre est le point fixe de Classe_Nombre.Donc Type_Reel est un type de la classe des nombres.

Des langages comme Smalltalk et Eiffel permettent le typage du second ordre.

? 3. Modélisation objet 

La modélisation objet consiste à créer un modèle informatique du système de l’utilisateur (un système informatique). Ce modèle peut rassembler aussi bien des éléments du monde réel que des concepts ou des idées propres au métier ou au domaine duquel fera partie le système. La modélisation Objet consiste à définir, à qualifier dans un premier temps ces élements sous forme de 

types, donc indépendamment de la mise en ?uvre. C’est ce que l’on appelle l'analyse orientée objet ou OOA (Object­Oriented Analysis).

Puis, on propose une ou des solutions techniques pour représenter les éléments définis dans le système informatique. C’est ce que l’on appelle la conception orientée objet ou OOD (Object­Oriented Design). Une fois un modèle de conception établi, il est possible au développeur de leur donner corps dans un langage de programmation. C’est ce que l’on appelle la programmation orientée objet ou OOP (Object­Oriented Programming). ? un modèle d’analyse peuvent correspondre plusieurs modèles de conception.

Pour écrire ces différents modèles, différents langages et méthodes ont été mis au point, dont OMT de Rumbaugh, BOOCH'93 de Booch et OOSE de Jacobson. Toutefois, ces méthodes ne permettaient de modéliser que certains types d’applications et se trouvaient limitées dans d’autres contextes. La méthode OMT prévalait sur l’ensemble des autres méthodes dans la première partie de la décennie 1990.

? partir de 1994, Rumbaugh, Booch et Jacobson ont décidé de s’unir dans l’élaboration d’une nouvelle méthode, suffisamment générique, pour pouvoir s’appliquer à quasiment tous les contextes applicatifs. Ils ont commencé d’abord par définir un langage de modélisation fortement inspiré de celles des méthodes des trois auteurs : UML (Unified Modeling Language). Une fois celui­ci pris en charge par l’OMG (Object Management Group), un organisme destiné à standardiser des technologies objet, comme CORBA (Common Object Request Broker Architecture), un intergiciel (middleware en anglais) objet réparti, Rumbaugh, Booch et Jacobson se sont attaqués à la méthode proprement dite: USDP (Unified Software Development Process). Cette méthode définit un cadre générique de développement objet avec UML comme langage de modélisation. USDP (généralement raccourci en UP) est une méthode itérative et incrémentale, centrée sur l’architecture et guidée par les cas d’utilisation et la réduction des risques. C’est aux concepteurs de s’attribuer cette méthode en l’instanciant à leur métier et à leur domaine. Dans l'industrie, deux grandes instances d'USDP existent : RUP (Rational Unified Process) et 2TUP (2 Tracks Unified Process).

Néanmoins pour un certain nombre de concepteurs objet, dont Bertrand Meyer, l’inventeur du langage orienté objet Eiffel, guider une modélisation objet par des cas d’utilisations est une erreur de méthode qui n’a rien d’objet et qui est plus proche d’une méthode fonctionnelle. Pour eux, les cas d’utilisations sont relégués à des utilisations plutôt annexes comme la validation d’un modèle par exemple.

? Sujets liés ? Modèles de conception    ? Simula    

? Bibliographie ? Brad J. Cox, Andrew J. Novobilski (1986). Object­Oriented Programming: An Evolutionary Approach, ISBN 0201548348. ? Bertrand Meyer    (2000). Conception et programmation orientées objet, ISBN 2­212­09111­7. ? Grady Booch   , James Rumbaugh, Ivar Jacobson (2000). Le processus unifié de  développement logiciel, ISBN 2­212­09142­7. ? Grady Booch   , James Rumbaugh, Ivar Jacobson (2000). Le guide de l’utilisateur UML, 

ISBN 2­2120­9103­6 ? G. Masini, A. Napoli, D. Colnet, D. Léonard, K. Tombre (1997). Les langages à  Objets, Langages de classes, langages de frames, langages d’acteurs, Interéditions, 584 p., ISBN 2729602755 ? De Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1999). Design Patterns, ISBN 2­7117­8644­7. ? Hugues Bersini (2004). L'Orienté Objet, ISBN 978­2­212­12084­4. 

? Lien externe ? Article Introduction à la POO Apprendre simplement la Programmation Orientée Objet ? Article Des paradigmes "classiques" à l'orienté objet ? Article Analyse et conception orientée objet avec UML et RUP, un survol rapide.

?  Articles en anglais The Theory of Classification de Anthony J.H. Simons sur le JOT (Journal of Object Technology) 

? Autres langues

• English    

2ème partie:  Concepts de programmation moderne : 

Approche objet en c++

Les notes de ce cours sont condensées dans un syllabus à part . Tout étudiant doit en faire sa propre copie. En plus, il est disponible en format électronique sur l'adresse:

http://www.burundisciences.afrikblog.com/

Pour toute information ou difficulté, consultez le professeur :NAHAYO Fulgence, Auteur  conceptionneur et réalisateur de ce blog(site).

!!!!!!!!!!!!!!!!!!!!! BONNE CHANCE   !!!!!!!!!!!!!!!!!!!!!!

Bujumbura  Septembre 2007

REPUBLIQUE DU BURUNDI

UNIVERSITE ESPOIR D'AFRIQUE

BP:238 BUJUMBURA­BURUNDI

PLAN DU COURS DES CONCEPTS DE PROGRAMMATION MODERNE

I. CONCEPTION DE LOGICIEL

1 Introduction

2 Définition

3 Les licences

4 Diverses présentations de logiciels

5 Développement de logiciels

II.  Capability Maturity Model Integration

1. Historique

2. Descriptif du modèle 

3. Les niveaux: 1,2,3,4,5

III.BOGUES

1. Définitions

2. Les effets

3. Approche formelle: Les méthodes formelles

4. Comment en faire?Comment s'en défaire?

5. Exemples

6. Bogues célèbres

7. Jeux vidéo

8. Les types de bogues particuliers

IV. Autres notions

1. Ouverture de code source

2. Développeurs

3. Logiciels critiques

4. Programmes informatiques et Langages de programmation

1. Langages à objet

2. Langages impératifs

3. Langages fonctionnels

4. Langages déclaratifs

5. Langages concurrents

6. programme informatique

7. Techniques de programmation

5. Fonction , Conception, Différences

V. Phase de réalisation ou de programmation (écriture et test programme)

1. Algorithmique

• 1 Définition 

• 2 Historique 

• 2.1 Antiquité 

• 2.2 Étude systématique 

• 3 Exemples d’algorithme 

• 4 Complexité algorithmique 

• 5 Quelques indications sur l'efficacité des algorithmes 

• 6 Les heuristiques 

• 7 Applications 

• 8 Voir aussi 

• 8.1 Liens externes 

2. Codage

3. Contrôle de version

• 1 Les versions 

• 2 Modifications et ensemble de modifications 

• 3 Branches 

• 3.1 Conflit de modifications 

• 4 Systèmes centralisés et décentralisés 

• 5 Fonctionnalités notoires des logiciels de gestion de version 

• 5.1 Étiquetage ou marquage 

4. Refactorisation

•  Pourquoi refactoriser ? 

• 2 Les niveaux de refactorisation 

• 2.1 Modification de la présentation 

• 2.2 Modification de l'algorithmique 

• 2.3 Relocalisation de procédures 

• 2.4 Refonte du design 

• 3 Des activités de refactorisation 

• 3.1 Suppression du code mort 

• 3.2 Ajout d'assertions 

• 3.3 Renommage 

• 3.4 Commentaires 

• 4 Références

5. Test unitaire

       6. Optimisation de code

                    1.  Pratique de l'optimisation 

• 1.1 Première approche 

• 1.2 Seconde approche 

• 2 Optimisation automatique 

• 2.1 Exemples 

• 2.1.1 Une spécificité du binaire : le décalage 

• 2.1.2 Le mot clef inline du C 

      7.  Packaging

VI. Modélisation

1. Méthodes de Modélisation

2. Méthode de développement

3. Langages de Modélisation

4. Approche objet

5. Les écueils classiques

VII. BASES DE DONNEES

? 1 Structure 

? 1.1 Bases de données hiérarchiques 

? 1.2 Bases de données réseaux 

? 1.3 Bases de données relationnelles 

? 1.4 Bases de données orientées objet 

? 1.5 Bases de données semi­structurées 

? 1.6 Bases de données multidimensionnelles 

? 1.7 Bases de données XML natives 

? 2 Schématisation de cette structure : le schéma conceptuel 

? 3 Contenu et utilisation 

? 3.1 Bases de données multimédia 

? 3.2 Bases de données décisionnelles 

? 3.3 Bases de données géographiques (SIG) 

? 3.4 Bases de données factuelles 

? 4 Voir aussi 

? 4.1 Article connexe 

? 4.2 Liens externes 

VIII. PROGRAMMATION ORIENTEE OBJET

? 1 Origines 

? 2 Les principes de bases 

? 2.1 L'objet (attribut et méthodes) 

? 2.2 Le typage et le polymorphisme 

? 2.3 La redéfinition 

? 2.4 Classe et prototype 

? 3 Le typage et la classification 

? 3.1 Le typage selon Liskov 

? 3.2 Le typage selon Cook 

? 4 Modélisation objet 

? 5 Sujets liés 

? 6 Bibliographie 

? 6.1 Lien externe 

BIBLIOGRAPHIE

? Brad J. Cox, Andrew J. Novobilski (1986). Object­Oriented Programming: An 

Evolutionary Approach, ISBN 0201548348. 

? Bertrand Meyer    (2000). Conception et programmation orientées objet, ISBN 2­212­

09111­7. 

? Grady Booch   , James Rumbaugh, Ivar Jacobson (2000). Le processus unifié de  

développement logiciel, ISBN 2­212­09142­7. 

? Grady Booch   , James Rumbaugh, Ivar Jacobson (2000). Le guide de l’utilisateur UML, 

ISBN 2­2120­9103­6 

? G. Masini, A. Napoli, D. Colnet, D. Léonard, K. Tombre (1997). Les langages à  

Objets, Langages de classes, langages de frames, langages d’acteurs, Interéditions, 584 

p., ISBN 2729602755 

? De Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1999). Design 

Patterns, ISBN 2­7117­8644­7. 

? Hugues Bersini (2004). L'Orienté Objet, ISBN 978­2­212­12084­4. 

Livres sur le CMMI

• Richard Basque, Un itinéraire fléché vers le Capability Maturity Model Intégration  

­ Version 1.2 , éditions DUNOD, 2006. 

• Dennis M. Ahern, Comprendre CMMI, une introduction pratique à l'amélioration de  

processus, traduction : Q­Labs, CEPADUES­EDITIONS, 2006. 

? Jean­Philippe Retaillé, Refactoring des applications Java/J2EE, Eyrolles, 2005, 390 p., 

ISBN 2212115776 

? Martin Fowler, Kent Beck, Refactoring: Improving the Design of Existing Code, Addison­

Wesley Professional, 1999, 464 p., ISBN 0201485672 

? Joshua Kerievsky, Refactoring to Patterns, Addison­Wesley Professional, 2004, 400 p., ISBN 

0321213351 

Concepts de programmation moderne : Approche objet en c++

Les notes de ce cours sont condensées dans un syllabus à part . Tout étudiant doit en faire sa propre  

copie. En plus, il est disponible en format électronique sur l'adresse:

http://www.burundisciences.afrikblog.com/

Pour toute information ou difficulté, consultez le professeur :NAHAYO Fulgence,

 Auteur programmeur­ réalisateur de ce blog(site).

 

52