FASCICULE INFORMATIQUE GENERALE - resoo.org · 5. La maintenance ... 4. Langages et processus de traduction ... d’organisation du travail (la taylorisation)

FASCICULE INFORMATIQUE GENERALE

Technologies logiciels Génie logiciel

AVERTISSEMENT

CET OUVRAGE CONTIENT DES REPRODUCTIONS EFFECTUEES PAR L'IGPDE AVEC L'AUTORISATION DU CENTRE FRANÇAIS D'EXPLOITATION DU DROIT DE COPIE (CFC).

TOUTE NOUVELLE REPRODUCTION EST SOUMISE A L'AUTORISATION PREALABLE DU CFC .

Sommaire

SOMMAIRE

CONDUITE DE PROJET ................................................................................................................... 7 1. Généralités ............................................................................................................................... 7 2. Le projet.................................................................................................................................... 8

2.1. Le schéma directeur ......................................................................................................... 8 2.2. Les systèmes d’information .............................................................................................. 8 2.3. Du schéma directeur au lancement du projet................................................................... 9 2.4. Définitions du projet .......................................................................................................... 9 2.5. Terminologie : conduite ou gestion de projet.................................................................. 10 2.6. Caractéristiques du projet ............................................................................................... 10 2.7. La problématique du projet ............................................................................................. 10

3. Cadre et méthodes de développement ............................................................................... 11 3.1. Le cadre méthodologique ............................................................................................... 11 3.2. Typologie des démarches méthodologiques .................................................................. 12 3.3. Les activités en conduite de projet ................................................................................. 16

4. L'organisation du projet........................................................................................................ 16 4.1. Les groupes .................................................................................................................... 16 4.2. Les intervenants du projet .............................................................................................. 17 4.3. Positionnement des intervenants au projet .................................................................... 17 4.4. Objectif et nécessité de conduire un projet .................................................................... 17

LES PHASES DU DEVELOPPEMENT DU LOGICIEL................................................................... 19 1. L'analyse ................................................................................................................................ 19

1.1. Présentation.................................................................................................................... 19 1.2. Principes à respecter ...................................................................................................... 20 1.3. L’analyse en informatique de gestion ............................................................................. 20

2. La programmation ................................................................................................................. 21 2.1. Présentation.................................................................................................................... 21 2.2. Les étapes de traduction ................................................................................................ 22

3. Les phases de tests .............................................................................................................. 22 3.1. Définition ......................................................................................................................... 22 3.2. Typologie des tests ......................................................................................................... 23

4. La mise en exploitation (mise en service) .......................................................................... 23 5. La maintenance ..................................................................................................................... 24

APPROCHES METHODOLOGIQUES DE L'ANALYSE................................................................. 26 1. Généralités ............................................................................................................................. 26 2. Les approches cartésiennes (1ere génération).................................................................... 26 3. L'approche systémique (2ème génération)........................................................................... 27 4. L'approche objet (3ème génération) ...................................................................................... 28 5. Les méthodologies "agiles" ................................................................................................. 28

5.1. Les valeurs...................................................................................................................... 29 5.2. Les principes................................................................................................................... 29 5.3. Les différentes méthodologies "agiles"........................................................................... 30

Toute reproduction même partielle interdite IGPDE page 3

Sommaire

LA PROGRAMMATION................................................................................................................... 35 1. Généralités.............................................................................................................................. 35 2. La programmation linéaire.................................................................................................... 35

2.1. L’algorithmie .................................................................................................................... 36 2.2. L'écriture du code source ................................................................................................ 40

3. La programmation événementielle ...................................................................................... 41 3.1. Les interfaces graphiques ............................................................................................... 41 3.2. Comparaison programmation structurée et programmation événementielle .................. 41

4. La programmation orientée objet......................................................................................... 42 4.1. Introduction...................................................................................................................... 42 4.2. Définition et Caractéristiques .......................................................................................... 42 4.3. Conclusion....................................................................................................................... 43

5. La programmation orientée aspect...................................................................................... 44 5.1. Présentation de la POA (Programmation Orientée Aspect)............................................ 44 5.2. Visualiser un système comme une suite de problèmes.................................................. 44 5.3. Le recoupement des problématiques et la problématique des recoupements ............... 45 5.4. Les fondements de la POA ............................................................................................. 46 5.5. Les bénéfices de la POA................................................................................................. 47 5.6. Implémentation du langage POA .................................................................................... 47

LES LANGAGES DE PROGRAMMATION ..................................................................................... 49 1. Généralités.............................................................................................................................. 49 2. Les générations de langage.................................................................................................. 50

2.1. Les langages de 1ere génération (L1G) ......................................................................... 51 2.2. Les langages de 2ème génération (L2G)........................................................................ 51 2.3. Les langages de 3ème génération (L3G)........................................................................ 52 2.4. Les langages de 4ème génération (L4G)........................................................................ 53 2.5. Les langages de 5ème génération (L5G)........................................................................ 53

3. Typologie des langages ........................................................................................................ 53 3.1. Les langages impératifs .................................................................................................. 54 3.2. Les langages procéduraux.............................................................................................. 54 3.3. Les langages orientés objets .......................................................................................... 55 3.4. Les langages déclaratifs (ou fonctionnels, ou orientes listes)......................................... 55 3.5. Les langages de requêtes............................................................................................... 56 3.6. Les langages de scripts................................................................................................... 57 3.7. Les langages descriptifs (ou hypertextuels).................................................................... 58

4. Langages et processus de traduction ................................................................................. 58 4.1. Les langages interprétés................................................................................................. 59 4.2. Les langages compilés.................................................................................................... 59 4.3. Avantages et inconvénients des deux mode de traduction............................................. 60

5. Description des principaux langages .................................................................................. 60 5.1. Langages procéduraux.................................................................................................... 60 5.2. Langages orientés-objet.................................................................................................. 62 5.3. Les langages de requête (SQL) ...................................................................................... 63 5.4. Les langages déclaratifs.................................................................................................. 63 5.5. Les langages de scripts................................................................................................... 64 5.6. Les langages descriptifs (ou hypertextuels).................................................................... 66

LES OUTILS D'AIDE AU DEVELOPPEMENT................................................................................ 69 1. Les Ateliers de Génie Logiciel (AGL)................................................................................... 69 2. Le développement par assemblage de composants ......................................................... 69

page 4 Toute reproduction même partielle interdite IGPDE

Sommaire

3. Les outils de développement visuels.................................................................................. 70

LA REINGENIERIE (RETRO-CONCEPTION) ................................................................................ 71 1. Domaine de couverture d'un référentiel documentaire..................................................... 71

1.1. Domaine de couverture d'un référentiel documentaire................................................... 71 1.2. Risques encourus avec une documentation périmée, perdue ou inexistante ................ 72

2. Démarche et les outils (méthodologique et logiciels) ....................................................... 73 2.1. Structure de projet et démarche à mettre en place ........................................................ 73 2.2. Démarche à suivre.......................................................................................................... 74 2.3. Outils méthodologiques (méthodes, AGL, logiciel) nécessaires .................................... 74

3. Contenu détaillé des travaux de "rétro-documentation" .................................................. 75 3.1. Contenu détaillé des travaux de l'étude préalable.......................................................... 75 3.2. Contenu détaillé des travaux de rétro-documentation.................................................... 76

4. Conclusion ............................................................................................................................. 77

CHRONIQUE page 5

Conduite de projet

CONDUITE DE PROJET

1. GENERALITES

La mise en oeuvre de principes méthodologiques de conduite de projet est une démarche relativement nouvelle dans les projets touchant au génie logiciel.

Cette nouvelle approche s’insère dans une démarche plus générale d’industrialisation de la production informatique. Son émergence actuelle s’explique par le niveau de maturité atteint par les organismes s’occupant de génie logiciel.

En matière d’ingénierie des systèmes d’information, l’état de l’art a fait une avancée importante. Sans doute, les progrès techniques de ces dernières années y sont-ils pour beaucoup. Bon nombre d’observateurs estiment qu’en la matière, on est passé d’un artisanat de métiers à une ingénierie des systèmes informatiques.

Les compétences et le talent dont ont fait preuve nos précurseurs ne sont pas en cause, mais de nouvelles contraintes dues aux impératifs économiques et techniques s’imposent et appellent des méthodes de développement plus rationnelles.

Ce même phénomène a été observé dans le monde industriel et dans le génie civil. Avec l’avènement de l’ère industrielle, de nouvelles méthodes sont apparues. Certaines erreurs de management ont été alors commises.

Citons à titre d’exemple le travail à la chaîne dans la mise en place des méthodes scientifiques d’organisation du travail (la taylorisation).

Les méthodes actuelles de conduite de projet s’inspirent des techniques déjà développées mais font appel dans une large mesure à des techniques de management plus modernes. Elles doivent concilier les impératifs économiques avec le désir d’épanouissement des hommes qui conçoivent les projets.

Les méthodes sont la mémoire de l’expérience. Elles formalisent la mise en oeuvre des techniques. A ce titre, le conducteur de projet doit en posséder la science. Mais en matière de génie logiciel, la production est, dans une large mesure, intellectuelle et répond à des critères très spécifiques. C’est pourquoi, la simple maîtrise des techniques de conduite de projet n’est pas une condition suffisante pour avoir les qualités requises d’un chef de projet performant.

Compétences techniques et qualités de management sont les deux facettes que doit posséder un conducteur de projet. Elles contribuent au succès de son entreprise.

Enfin, il faut savoir que la conduite de projet n’est pas une science exacte et que souvent la progression ne se fait qu’au travers des erreurs commises.


Conduite de projet

2. LE PROJET

2.1. Le schéma directeur

Les grandes orientations définies dans le schéma directeur, découpé en grands domaines, structurent les projets. Les projets préfigurent les applications futures.

Le schéma directeur est la planification stratégique de l’organisme dans ses domaines d’action. Le schéma directeur informatique, sous ensemble spécifique du schéma directeur, fixe les grandes orientations en matière de politique d’informatisation. Il est défini pour une période en générale de 5 ans, et est régulièrement actualisé.

Exemples de domaine d’orientation : ♦ acquisition des matériels, stratégie de sous-traitance, ♦ développement des réseaux de communication, ♦ politique d’achat des logiciels, middle-ware, ♦ engagement des développements d’applications par domaine etc...

2.2. Les systèmes d’information

On définit le système d’information comme l’ensemble abstrait de l’ensemble des données mémorisé dont a besoin un organisme pour être opérationnel.


Conduite de projet

Le système d’information recouvre les grands domaines de l’activité générale. A chaque domaine correspond un système d’information (SI), voire plusieurs.

L’interdépendance des supports de l’information au sein de plusieurs projets est possible. Le projet, en appui de plusieurs systèmes d’information, intègre l’ensemble de l’information. Le chef de projet assure la communication avec les autres responsables d’application et l’intégration du projet avec les autres applications.

2.3. Du schéma directeur au lancement du projet

La réflexion la plus générale, notamment sur les études de faisabilité et d’opportunité, est formalisée au niveau du schéma directeur ou du schéma directeur informatique.

Toutefois, le schéma directeur ne fige pas la planification. En effet, un projet peut répondre à une sollicitation inopinée, à une demande d’évolution fonctionnelle impromptue. La maintenance évolutive s’assimile à un projet à part entière et est conduite de façon similaire.

Les procédures de lancement de projet et de nomination de chef de projet sont internes et relatives à l’organisation générale; la phase de lancement, pour concrétiser le projet, doit revêtir un caractère formel.

Cette clarification se traduit par l’établissement et la programmation de : ♦ la lettre de mission, nommant le chef de projet et lui donnant ordre de mission de commencer

un projet. Les grandes lignes du projet notamment les objectifs et les contraintes doivent y être définies :

♦ la réunion de lancement du projet, regroupe les responsables du projet (niveau management), le chef de projet, les consultants éventuels et les partenaires du projet.

En résumé, il est essentiel de se souvenir que le projet, sauf exception, s’insère dans le contexte général de l’entreprise ou de l’administration. Ce contexte préexistant se définit comme : ♦ le schéma directeur, ♦ le parc applicatif, ♦ les normes et les standards, ♦ la mise en oeuvre du plan d’assurance qualité, ♦ l’existence de dictionnaires et de référentiels, ♦ l’environnement matériel, structurel, organisationnel.

Le chef de projet prend connaissance de ce cadre pour initier ses premiers travaux. Cette étape contribue et conditionne l’insertion du produit fini dans le parc applicatif.

2.4. Définitions du projet

La notion de projet recouvre plusieurs aspects; cela explique la pluralité des définitions du projet selon que l’on appréhende le projet sous ses aspects procéduraux ou organisationnels.

DEFINITION AFNOR DU PROJET (NORME X50-106) "Démarche spécifique qui permet de structurer méthodiquement et progressivement une réalité à venir. Un projet est défini et mis en oeuvre pour élaborer une réponse au besoin d’un utilisateur, d’un client ou d’une clientèle, et il implique un objectif et des actions à entreprendre avec des ressources données".


Conduite de projet

DEFINITION ORGANISATIONNELLE DU PROJET "Un projet est une articulation de ressources humaines, intellectuelles et matérielles agencées dans une organisation temporaire, dans le but d’atteindre un objectif caractérisé par un coût, un délai et des performances".

DEFINITION PROCEDURALE "Un projet est la procédure permettant de passer d’un problème à une solution par le biais d’un plan : le projet".

DEFINITION RETENUE DANS LE CADRE DE SAPHIR "La réalisation d'un produit par une équipe, pour satisfaire un objectif prédéfini tout en respectant certaines contraintes".

Le schéma des processus internes de la conduite de projet (planification initiale et suivi)

2.5. Terminologie : conduite ou gestion de projet

On évoque la conduite de projet quand on axe son propos sur l’aspect organisationnel du projet alors que l’on parle de gestion de projet pour souligner l’aspect technique de la conduite de projet. Les deux appellations se confondent dans la réalité.

2.6. Caractéristiques du projet

Les caractéristiques du projet sont : ♦ une limitation dans le temps : un projet a un début et une fin, ♦ des objectifs précis en termes de délais, de coût (consommation) et de performances

attendues, ♦ une réalisation unique : un projet n’est pas une activité et a fortiori elle n’est pas répétitive, ♦ un avenir incertain : un projet comporte nécessairement une part de risque, ♦ une complexité nécessitant un important travail d’analyse excluant l’improvisation, ♦ une organisation humaine spécifique et temporaire.

2.7. La problématique du projet

Indépendamment de la taille du projet, réussir un projet informatique, c’est obtenir un produit répondant aux besoins de l’utilisateur final, à tous ses besoins exprimés mais rien qu’à ses besoins. De plus le produit doit avoir respecté les contraintes prédéfinies en termes de coût, de délais et de qualité.

La mise en place très tôt dans le cycle de vie d’un plan qualité est un facteur déterminant de réussite d’un projet.


Conduite de projet

Le chef de projet doit avoir présent à l’esprit que la conduite de son projet passe par la gestion des ressources humaines. Le chef de projet conduit mais ne fait pas le projet. Il doit s’impliquer pour réussir en faisant réussir les autres.

Le chef de projet, maître d’œuvre du projet, à la mission de concilier trois objectifs par nature antagonistes : le coût, la qualité et les délais.

Le chef de projet justifie le compromis Coût Qualité Délai en fonction des contraintes générales du projet.

3. CADRE ET METHODES DE DEVELOPPEMENT

3.1. Le cadre méthodologique

Le cadre méthodologique définit l’ensemble des techniques et des savoir-faire qui concourent à la réalisation des projets. C’est l’expérience formalisée, le bien commun de l’entreprise ou de l’administration. Il définit un ensemble structuré de règles qui coordonnent et codifient l’action de toutes les parties prenantes à un projet d’informatisation. Il couvre l’ensemble du cycle de vie du projet.

Le savoir-faire relatif à la conduite de projet fait partie du cadre méthodologique. Le chef de projet doit donc s’y conformer dès lors qu’un cadre méthodologique préexiste au projet.

Dans les grandes entreprises ou administrations, le cadre méthodologique est géré par une structure spécialisée. Cette structure fédéralise et formalise l’ensemble des méthodes utilisées


Conduite de projet

dans l’entreprise ou l’administration. Elle se situe, généralement, très haut dans l’organigramme, eu égard à son activité transversale. Historiquement, ce type de structure voit le jour dès lors que des processus d’industrialisation sont mis en oeuvre. A l’origine, l’appellation consacrée est bureau des méthodes.

Le chef de projet doit se rapprocher de cette structure pour prendre connaissance des méthodes employées.

3.2. Typologie des démarches méthodologiques

La démarche méthodologique est la réponse au "comment faire ?". Une méthode de conception est constituée des éléments suivants : ♦ une terminologie propre à la méthode, ♦ un formalisme orienté sur la représentation des données et des traitements, ♦ un mode de progression dans le cours du processus définissant le passage d’une étape à une

autre, ♦ une analyse qui fasse abstraction de l’environnement machine, ♦ une démarche de conception.

Une démarche de conception décrit le mode de progression du processus et de ce fait à une influence directe sur la planification du projet.

3.2.1. LA DEMARCHE PAR PROTOTYPAGE

Elle concerne essentiellement les techniques de validation des besoins utilisateurs ou des spécifications des systèmes complexes. Ces techniques s'inspirent de celles que l’industrie utilise couramment dans l'industrie pour la conception de produits.

Un des intérêts majeurs des démarches par prototypage réside dans le caractère vivant et concret de l'étape d'étude: par l’expérimentation des propositions fonctionnelles, ergonomiques et techniques, on autorise à chaque itération une validation des besoins de l'utilisateur. Le résultat d'un prototype correspondra aux spécifications détaillées et validées d'un système, d'une fonction ou d'une application.

Cette technique est de plus en plus utilisée, sous la forme de maquettage dynamique, pour le développement d'applications d'informatique de gestion, en raison de son intérêt pour la spécification des interfaces homme-machine, interfaces de plus en plus complexes et essentielles dans la réussite du développement d'une application. Des outils de développement performants et des environnements logiciels plus accessibles et opérationnels en facilitent l’utilisation.

Le prototypage n'est pas la seule étape du cycle de vie du projet car cette technique et sa mise en œuvre peuvent s'intégrer ou s'adapter à d'autres types de démarches.


Conduite de projet

La démarche par prototypage avec l’itération développement évaluation.

3.2.2. LE MODELE DIT DE LA CASCADE

Ce modèle inspire de nombreuses méthodes et sert de base notamment à la démarche préconisée dans la méthode Merise. Il tire son nom de l'image de la descente en cascade d'une étape à une autre dans le cycle de vie du projet.

Ce modèle, le plus utilisé dans les approches classiques de type système d'information, est particulièrement adapté à la mise en place de points de contrôle qualité pour la conduite du projet (état d'avancement, résultats, planning, suivi ...). Il est également recommandé pour servir de base à la gestion des rapports contractuels entre maître d'œuvre et maître d'ouvrage.

Cette démarche se caractérise également par une production documentaire relativement standardisée à chacune de ses étapes.

Pour rompre une certaine rigidité de cette démarche (nécessité d’être dans un état stabilisé pour passer d’une étape à une autre), des variantes autorisent une itération (toutefois limitée) entre deux étapes.


Conduite de projet

3.2.3. LE MODELE EN SPIRALE OU DEVELOPPEMENT RAD

Les démarches en spirale (BOEHM) et le développement rapide d'applications (RAD, james martin) relèvent d'un courant s'opposant aux démarches en cascade, jugées trop lourdes et trop contraignantes pour le développement de petites et moyennes applications.

Ces démarches supposent qu'au début du processus de développement, l'utilisateur n'a qu'une idée très sommaire de ses besoins. Elles se proposent donc de rendre progressives et pratiquement simultanées avec la conception et la réalisation l'expression et la spécification des besoins.

Ces démarches s'appuient, d'une part sur des préconisations d'organisation du travail, où notamment les utilisateurs sont associés de manière continue à l'ensemble du cycle de développement jusqu'aux tests finaux, et d'autre part sur les techniques de prototypage telles qu'elles ont été évoquées ci-dessus.

Ces démarches imposent un découpage relativement fin de l'application dès le début du projet. Chaque fonction ou lot découpé suit les différentes étapes de spécifications, tests, améliorations, jusqu'à la finalisation complète du projet. Ces itérations successives suggèrent l'image d'une spirale dont chaque cycle se rapprocherait un peu plus de la fin du projet.

Schéma de principe du développement rapide d’application (dit en spirale)

La démarche RAD est une réponse, d’une part à l’émergence de nouvelles architectures du type client-serveur ou micro-informatique et d’autre part, aux carences de démarche dite en cascade où l’effet tunnel (1) est ressenti comme une entrave de la part des utilisateurs qui éprouvent des difficultés à formaliser et stabiliser les spécifications. 1 Temps de latence entre la phase de spécification et la présentation du produit aux utilisateurs. Cette phase est importante avec l’application stricte de MERISE

La démarche RAD doit, pour sa réussite, beaucoup à l’implication des utilisateurs et au rôle particulier de l’animateur de projet, chef d’orchestre assurant le lien entre utilisateurs et informaticiens.

La démarche propose, avant l’amorçage de l’itération sur la phase de prototypage, deux séminaires espacés de quelques semaines.

Le premier, le JRP (Joint Requierement Planning) réunit les utilisateurs et les informaticiens pendant deux à trois jours. L’objectif est d’obtenir un consensus sur le planning de livraison des différents prototypes, de lever les ambiguïtés et de définir le contenu fonctionnel des différentes versions.

Le second, le JAD (Joint Application Design) a pour objectif de valider les choix fonctionnels et techniques ainsi que l’ergonomie du logiciel. A l’issue du JAD, un cahier des charges est produit permettant l’enchaînement sur le premier prototype. Ce premier prototype est examiné par le focus group, groupe utilisateur qui avec l’aide de l’animateur de projet recueille et encadre les modifications à apporter au premier prototype. Ensuite le processus devient itératif sur quelques cycles.


Conduite de projet

Schéma de fonctionnement du RAD soulignant la phase préalable de spécification par le biais de

séminaires JRP et JAD

3.2.4. LES DEMARCHES DITES EXPLORATOIRES

Elles ont été formalisée pour le développement des systèmes de type intelligence artificielle. Elles sont exclusivement réservées au développement logiciel et non à une approche de type système d'information.

Ces démarches utilisent la programmation exploratoire basée sur le principe d'une itération rapide entre le développement d'une proposition, l'utilisation d'un module, la recherche de son adéquation et sa correction.

Le résultat obtenu ne peut être comparé à aucune spécification et ne peut donc être validé, mais simplement accepté en tant que tel. Ce type de démarche peut être utilisé lorsqu'il est difficile ou impossible d'établir des spécifications détaillées d'un système préalablement au développement, ou lorsque les besoins utilisateurs ne sont pas exprimés ou difficilement formalisables.


Conduite de projet

3.3. Les activités en conduite de projet

La conduite de projet est composée de plusieurs activités, de plusieurs talents, se distribuant tout au long du projet. C’est une tâche hamac (2) entre le début et la fin du projet et non une tâche planifiée au début des études. (2) une tâche hamac est une tâche dont le début et la fin sont conditionnés par la tâche qui la précède et la tâche qui la suit. Ici, c’est le jalon de début et de fin du projet qui conditionne la tâche conduite de projet.

Les activités du chef de projet ne s’arrêtent donc pas à son rôle, certes important, de planificateur, mais intègrent largement des compétences de management. La tableau suivant identifie les activités propres à la conduite de projet informatique et analyse les causes les plus fréquentes de dérive :

activité causes de dérive

spécifications vagues, incomplètes, non stabilisées découpage du projet niveau inadapté estimation fausse, oubli, précision insuffisante affectation des ressources mauvaise distribution, conflit, rétention d’information planification initiale contraintes omises suivi écart non détecté à temps contrôle tests insuffisants, non planification des points de contrôle documentation inexistante ou incomplète

4. L'ORGANISATION DU PROJET

4.1. Les groupes

Le projet est une entreprise collégiale. Les différents partenaires sont distribués en groupes ayant chacun un niveau de préoccupation différent. C’est la garantie de tenir compte de tous les impératifs du projet.

Ainsi, le niveau de préoccupation du groupe utilisateur (représentant l’ensemble des utilisateurs) est nécessairement différent du groupe de pilotage qui a une vision plus opérationnelle du projet.


Conduite de projet

Le chef de projet veille à respecter le niveau de responsabilité de chacun des groupes. Une décision stratégique pour le projet sera prise par le groupe de pilotage, alors que la validation d’une session ou d’une transaction composée d’écrans est validée par le groupe utilisateur.

4.2. Les intervenants du projet L’utilisateur l’analyste le chef de projet le programmeur le consultant l’exploitant l’expert l’administrateur de données l’organisateur le responsable qualité

Cette liste n’est pas exhaustive. Le chef de projet a une parfaite connaissance des attributions, des compétences et des degrés de responsabilité de chacun. Cela revêt une importance notamment dans la distribution (affectation) des rôles dans le projet.

4.3. Positionnement des intervenants au projet

Ce schéma illustre les pôles de compétence au sein d’un projet. Il est à noter qu’il peut y avoir des évolutions et des changements de compétence dans la distribution des rôles en fonction des étapes du projet.

4.4. Objectif et nécessité de conduire un projet

Le projet est une entité complexe, impliquant d’importantes responsabilités, mettant en oeuvre différents partenaires qui doivent dialoguer et collaborer. Les ressources sont limitées (délais, ressources humaines, ressources matérielles). Les objectifs sont définis.

Conduire un projet, c’est établir un plan pour atteindre dans les meilleurs conditions un objectif. Les arguments les plus fréquemment avancés contre la planification sont : ♦ elle est dispendieuse de temps, ♦ elle est difficile à suivre, ♦ elle n’est pas le reflet de la réalité, ♦ on fait dire au plan ce que l’on veut bien lui faire dire, ♦ elle impose un discipline, ♦ le futur est par définition imprévisible, ♦ le risque d’erreur est important, les taux d’incertitude masquent la réalité.


Conduite de projet

La réalité montre l’importance de l’objectif pour le projet. Le projet, lui, montre l’importance du plan comme moyen de mettre en action la synergie des équipes, la confiance en l’objectif commun, l’apport de visibilité des travaux entre les parties prenantes au projet, la clarification et la présentation des enjeux nécessaires au groupe pour permettre une validation de qualité.


Les phases du développement du logiciel

LES PHASES DU DEVELOPPEMENT DU LOGICIEL

Les premiers programmes d'ordinateurs avaient été fabriqués par des mathématiciens et des scientifiques qui pensaient que le travail était simple et logique.

Le logiciel s'est révélé plus difficile à développer qu'ils ne l'avaient supposé.

Les ordinateurs étaient têtus. Ils s'obstinaient à faire ce qui était écrit plutôt que ce qui était voulu.

Le résultat fut qu'une nouvelle race d'artisans prit le relais pour faire le travail. Ils n'étaient souvent ni mathématiciens, ni scientifiques mais ils étaient profondément engagés dans une aventure avec les ordinateurs, une aventure précurseur d'une nouvelle technologie.

Les phases du développement d'un logiciel consiste principalement : ♦ à analyser l’ensemble du domaine à automatiser : c’est la phase d’analyse, ♦ à produire les programmes sources de l’application correspondante : c’est la phase de

programmation ; ♦ enfin à tester et à recetter la future application avant sa mise en œuvre (mise en exploitation).

1. L'ANALYSE

1.1. Présentation

On désigne par analyse "l'ensemble des activités qui consistent à concevoir l'automatisation d'un domaine d'activité d'une entreprise ou d'une administration".

La conception consiste à définir : ♦ l'organisation de l'automatisation proposée ("QUI", "FAIT", "QUOI", COMMENT") ; ♦ les données et les traitements nécessaires ; ♦ l'environnement technique, intégrant matériels et logiciels. L’analyse est l’ensemble des opérations préalables à la réalisation d’une application informatique.

Le processus de construction d'une application est en fait une suite de traductions. ♦ Dans un premier temps, le système "existant" (c'est-à-dire les procédures manuelles ou

informatiques en place) est étudié et traduit pour en obtenir une définition abstraite ne faisant apparaître que la logique des processus en cause et les informations qu'ils produisent, conservent ou consomment.

♦ Puis, avec les futurs utilisateurs de l'application, seront exprimés les besoins du nouveau système qui reprendra probablement des fonctionnalités de l’ancien système, tout en prenant en compte les nouvelles fonctionnalités définies par les utilisateurs.

♦ Cette nouvelle définition du système sera la base nécessaire pour la construction de la nouvelle application.

Cette approche historique du système a cependant quelques limites. Elle convient bien en effet lorsque la nouvelle application va conserver au moins 50% des fonctionnalités de l'ancienne



application. Dans la plupart des cas, l'application existante est antique et sa conception a beaucoup souffert des maintenances successives, parfois décidées dans l'urgence. Il n'est donc pas judicieux de reprendre cette conception sauf pour quelques procédures.

Il sera alors préférable d'analyser directement les nouveaux besoins exprimés par les utilisateurs et de se focaliser sur la construction de la nouvelle application. Puis les procédures résultant de l'analyse pourront être confrontées aux procédures existantes pour en apprécier la faisabilité.

1.2. Principes à respecter En premier lieu, lorsqu’une méthode est préconisée pour la phase de développement, il convient de l’utiliser et de la respecter au mieux, selon le contexte applicatif.

Ensuite se déroulent normalement les différentes phases de l’analyse traditionnelle avec des rencontres de mise au point chaque fois que cela est nécessaire ; notamment lorsqu’une décision conditionnant la suite est à prendre par les responsables.

Enfin, le travail des analystes est concrétisé par le dossier d’analyse qui servira de point de départ au travail des programmeurs.

Cet aspect est particulièrement important et mérite d’être détaillé :

♦ l’analyste dispose d’un chantier qui lui est propre ou qu’il partage avec quelques collègues ; ♦ son but immédiat est de produire un résultat qui marquera la fin de son travail ; ♦ cependant, la production de ce résultat ne coïncide pas forcément dans la forme au besoin du

programmeur en termes de clarté et de documentation. Pour éviter de produire des documents difficilement exploitables, deux règles essentielles doivent être respectées :

♦ documenter au plus tôt, ♦ vérifier, une fois le dossier prêt, qu’il est utilisable. Le premier point signifie qu’il ne faut pas attendre d’avoir terminé toute son analyse pour aborder l’aspect documentaire.

1.3. L’analyse en informatique de gestion L’étude des organisations montre qu’elles pilotent leur activité selon plusieurs niveaux de décision :

♦ stratégiques ; ♦ tactiques ; ♦ et opérationnelles.

Le niveau stratégique définit les objectifs à long terme de l’organisation. Ce niveau de décision met en jeu la raison d’être de l’organisation en toute ou partie (exemple : localisations d’usines) et ne débouche pas obligatoirement sur des finalités directement opératoires.

Le niveau tactique définit les objectifs à moyen terme. Souvent les décisions de ce niveau sont organisées selon les implémentations des locaux de l’entreprise ou de l’administration.

Enfin, le niveau opérationnel permet de définir les objectifs à court terme, souvent assortis de mesures quantitatives.

Lors de ces prises de décision, l’information est traitée selon une ou plusieurs opérations telles que son enregistrement et son stockage, son classement momentané ou définitif (archivage), sa consultation, la modification de sa présentation, la modification de son contenu et/ou sa transmission à distance.



Exemples de décisions stratégiques

localisation d’usines ou de magasins

sélection de responsables

lancement de nouveaux produits

Exemples de décisions tactiques

modification de tarification

politique de gestion des stocks

Exemples de décisions opérationnelles :

tenue quotidienne des stocks

suivi de paiement client

ordonnancement de production

L’activité de gestion est l’ensemble des moyens et des méthodes permettant de contrôler l’activité opérationnelle en conformité avec les objectifs à moyen et long terme des niveaux tactique et stratégique.

L’informatique de gestion utilise les opérations décrites ci-dessus pour automatiser l’activité de gestion.

L’analyse informatique a pour but d’étudier le fonctionnement d’une organisation pour en dégager les objets et les procédures qui permettent l’activité de gestion.

L’informatique automatise les procédures. À cet effet, les données, représentant les objets constitutifs de l’organisation, sont organisées en fichiers et/ou en bases de données.

2. LA PROGRAMMATION

2.1. Présentation

Pour cette phase, l’analyste a produit un dossier d’analyse qui représente pour l’équipe de programmation une sorte de canevas qui détaille l’enchaînement des opérations à réaliser par le système d’information. Les programmeurs, éventuellement assistés de programmeurs systèmes, s’attacheront à produire les sources des programmes qui constitueront l’application.

Le programmeur verra son travail réellement terminé lorsqu’il aura produit ses dossiers ; à savoir le dossier de programmation et le dossier d’exploitation (guide utilisateur).

Le dossier de programmation comporte l’intégralité des documents que le programmeur a été amené à produire tout au long de son travail. C’est ainsi que l’on y retrouvera, entre autres : ♦ les dessins d’organigrammes ou arbres programmatiques, ♦ les sources de ses programmes, ♦ les tables de décision qu’il a produites, ♦ les jeux d’essai constitués pour ses tests, ♦ les tables de correspondance utilisées, ♦ les structures des articles et des fichiers.

Ce dossier est essentiel en matière de maintenance. En effet, de nombreux mois après l’écriture des programmes, il peut s’avérer nécessaire de réviser une partie du code.

Si un bon dossier existe, n’importe quel programmeur compétent dans le langage utilisé sera à même d’effectuer les modifications demandées.



Si le dossier n’existe pas ou est mal conçu, la maintenance devient impossible. D’où l’importance d’accorder le plus grand soin à la rédaction de ce dossier et de le constituer au même rythme que l’avancement du développement lui-même.

Le dossier d’exploitation doit permettre aux utilisateurs de tout savoir sur la mise en œuvre l’application sans se poser de questions. Les manipulations ainsi que les différentes fonctionnalités doivent être documentées et accompagnées d’exemples clairs.

En outre, le dossier doit comporter la liste des messages d’erreurs prévus ainsi que leur signification et la conduite à tenir lors de leur apparition. Enfin, les procédures de remontée d’incident doivent être clairement définies afin d’éviter toute perte de temps.

Le temps consacré à la réalisation du guide utilisateur s’avère également un gain de temps pour la maintenance et le suivi de l’application.

2.2. Les étapes de traduction

Généralement, les programmes écrits en langage source subiront une suite de transformations nommée "compilation". En fait, ce terme recouvre différentes phases d’analyse et de transformation du programme origine. Ces phases sont : ♦ la précompilation, ♦ la compilation, ♦ l’assemblage, ♦ l’édition de liens.

Le précompilateur supprime les commentaires, interprète les directives de compilation conditionnelle et remplace les mots définis (macros, constantes) par les valeurs qui leur sont associées.

3. LES PHASES DE TESTS

3.1. Définition

Le test est l'exécution ou l'évaluation d'un programme (ou d'un composant de ce programme) par des moyens automatiques ou manuels, pour vérifier qu'il répond à ses spécifications ou identifier les différences entre les résultats attendus et ceux obtenus.

La recette est un acte contractuel visant à vérifier si l'application est conforme aux spécifications décrites dans le cahier des charges et à définir si elle est recevable ou non. La recette relève de la compétence de la maîtrise d'ouvrage.

Pour prononcer la recette, il faut donc faire les tests afin de vérifier la conformité aux spécifications de l'application.



3.2. Typologie des tests

3.2.1. TESTS UNITAIRES

Les tests unitaires ont vocation à vérifier le bon fonctionnement d'un programme unitaire (ou d'un module) après son codage. Ils sont souvent appelé "tests du programmeur" car ils relève de la responsabilité de ce dernier.

3.2.2. TESTS D’INTEGRATION

Les tests d’intégration sont les tests des différentes parties qui ont été développées et testées séparément par les équipes d’analyse et de programmation. Certains membres de l’équipe de projet ont été désignés pour effectuer cette tâche d’intégration. Leur rôle consiste à vérifier que chaque partie de l’ensemble est capable de fonctionner avec le reste et d’aboutir aux résultats généraux attendus du projet.

Ces tests doivent donc être conçus de manière à se rapprocher au plus près de l’exhaustivité des cas afin d’éviter d’éventuelles surprises. L’enchaînement de toutes les tâches permettant de dérouler un certain nombre de cas de bout en bout sera testé et les résultats consignés par écrit.

S’il s’avère que les tests mettent en lumière une incompatibilité entre certaines parties de l’application, il sera nécessaire de procéder à une rectification du projet.

3.2.3. TESTS DE NON REGRESSION

Les tests de non régression s'assure que toute modification apportée à une partie de programme (ou module) n'altère pas le bon fonctionnement des autres parties.

3.2.4. TESTS DE VALIDATION

Les tests de validation permettent de s'assurer de la conformité de l'application aux spécifications décrites dans le cahier des charges par la maîtrise d'ouvrage.

4. LA MISE EN EXPLOITATION (MISE EN SERVICE)

Les différents travaux qui sont soumis à l’ordinateur nécessitent des opérations bien précises de la part du personnel attaché à sa conduite. Un certain nombre de prescriptions doivent être respectées pour poser les bases de vos recherches personnelles.

En tout premier lieu, l’ordinateur doit être opérationnel, avant même que des travaux lui soient soumis : ♦ Le démarrage de la machine s’est il effectué dans de bonnes conditions ? (Vous pouvez le

vérifier en vous rendant sur un écran relié au système et en interrogeant ses fichiers « log » ou de démarrage. Profitez-en pour les étudier de près)

♦ Les périphériques sont-ils en état de fonctionnement correct ? ♦ Les unités de préparation et de finition sont-elles prêtes ? ♦ Les personnels nécessaires pour mettre en œuvre les différents travaux de la journée ou de la

période intéressée sont-ils présents ? Sinon, y a-t-il des remplaçants ? ♦ Disposons-nous des données d’entrée prévues dans les traitements (bandes, disques, fichiers

permanents ou temporaires) ?



♦ Les logiciels devant être mis en œuvre sont-ils présents sur les supports appropriés ? S’agit-il des versions adéquates ?

Toutes ces questions, que l’on doit se poser au vu des plannings des travaux et des dossiers d’exploitation, doivent trouver une réponse favorable pour que les travaux puissent débuter. Si ce n’est pas le cas, il convient de mettre en œuvre les procédures appropriées ; à savoir : ♦ prendre contact avec la hiérarchie si des choix sont nécessaires ; ♦ étudier les solutions de remplacement (machine de backup…) et les proposer aux décideurs ; ♦ envisager une modification exceptionnelle des rythmes de travail sachant que cette solution est

à manier avec précaution vis-à-vis du personnel de salle, de préparation et de finition ; ♦ éventuellement prévenir les services destinataires des résultats des traitements des retards

susceptibles d’intervenir dans la production.

Toutes ces précautions ayant été prises et les vérifications effectuées, les travaux de la journée vont pouvoir commencer.

Aboutissement du travail de la période concernée, les travaux de finition sont essentiels. En effet, à quoi servirait d’avoir pris toutes les précautions nécessaires pour la bonne production des résultats si ceux-ci n’étaient pas adressés à leurs destinataires dans la forme et les délais qui conviennent. Ceux-ci sont d’ailleurs normalement définis dans les différents dossiers d’exploitation.

5. LA MAINTENANCE

La maintenance est une phase particulièrement importante au regard de la bonne marche de l’exploitation.

L’aspect maintenance de l’application doit avoir été prévu dès les premiers programmes terminés. Il convient de souligner l’importance des choix retenus au niveau de l’étude (découpage en modules courts et indépendants, respect d’un standard de programmation, utilisation de commentaires…) qui entraîne des facilité en termes de maintenance. Des programmes courts et bien structurés accompagnés de commentaires nombreux et clairs permettront de diminuer les temps de maintenance et d’éviter des erreurs dues à l’incompréhension du contexte de programmation. La solution la plus simple sera toujours la meilleure.

En effet, à l’occasion d’un premier déploiement, les utilisateurs rencontrent des cas qui n’ont peut-être pas été testés dans les mêmes conditions que celles de leur exploitation. Il peut en résulter un certain nombre d’anomalies rapidement décelées qu’il convient de corriger au plus tôt. Normalement, le temps et l’expérience aidant, le nombre d’incidents devra fortement diminuer.

On distingue trois types de maintenance pouvant intervenir au niveau d’une exploitation : ♦ La maintenance corrective nécessité par un dysfonctionnement de programme (non décelé

lors des tests) ; ♦ La maintenance évolutive due à une modification du cadre réglementaire ou à la prise en

compte de nouvelles fonctionnalités ; ♦ La maintenance adaptative nécessité par une migration de l'environnement technique (matériel

et/ou logiciel) du centre d'exploitation.




Approches méthodologiques de l'analyse

APPROCHES METHODOLOGIQUES DE L'ANALYSE

1. GENERALITES

Il existe plusieurs méthodes d'analyse. Mais quelles que soient leurs différences, elles conduisent toutes à réaliser des activités similaires lors de la phase d’analyse, et principalement l’identification et la formalisation des principaux objets de gestion de l’organisme étudié, ainsi que les modes de gestion de leurs activités.

L'identification consiste à rechercher, et à trouver, les concepts ou objets qui composeront le futur système. Il ne s'agit pas, malgré les apparences, d'une tâche facile puisqu'il faut en même temps éviter d'identifier des besoins inutiles et ne pas faire d'impasse sur des besoins essentiels. De plus, la facilité d'obtention, la qualité et la quantité des informations à recueillir sont très variables selon les projets. Il est prudent d'anticiper et d'adopter une stratégie qui permette de gérer la complexité et le volume des spécifications, lorsqu'elles sont trop nombreuses ou, dans le cas le plus fréquent, d'obtenir les spécifications manquantes. Les techniques d'analyse de la valeur permettent de hiérarchiser les besoins et de leur affecter des priorités.

En informatique de gestion, trois approches prédominent : l’approche cartésienne, l’approche systémique et l’approche objet. Voyons dans ce qui suit, leur présentation.

Trois approches méthodologiques prédominent. La connaissance des traits particuliers de ces différentes approches est utile pour l’élaboration de passerelles méthodologiques. En effet, les outils d'aide au développement d'application font souvent appel aux principes d'une méthode qu'ils particularisent. Disposer de points de repères méthodologiques permet de se concentrer sur les tâches d'analyse à accomplir et d'éviter de se focaliser sur les spécificités de l'outil.

2. LES APPROCHES CARTESIENNES (1ere GENERATION)

La première génération des méthodes (années 70) inclut les méthodes d’analyse fonctionnelles (ou d’analyse structurée) qui considèrent une fonction à la fois et proposent de la découper de façon hiérarchique en un ensemble de sous-fonctions jusqu’à ce qu’un niveau suffisamment fin soit atteint pour pouvoir réaliser un codage simple.

Les activités (ou processus) du domaine sont découpées de façon descendante (hiérarchique) selon les principes formulés par Descartes.

Les méthodes de programmation structurée, issues des années 70, illustrent bien cette approche (exemples : SADT, Jackson Structured Programming, Yourdon)

Elles sont caractérisées par les points forts suivants : ♦ la simplicité, car la démarche est naturelle et appelle au bon sens ; ♦ la facilité de capture des besoins des utilisateurs ; ♦ l’existence de plusieurs niveaux d’abstraction pour une même solution.



Elles présentent cependant les points faibles suivants : ♦ concentration de l’effort de l’analyse sur les fonctions, ce qui néglige la cohérence des

données et induit une redondance (une même donnée dans plusieurs modules) ; ♦ absence de règles de décomposition explicites, ce qui induit des différences de décomposition,

et notamment de hiérarchies, selon les développeurs ; ♦ difficulté de prise en compte des interactions non hiérarchiques dans le cas de systèmes

complexes ; ♦ reconception importante du fait du caractère plus instable des fonctions par rapport aux

données (on parle de volatilité relative des fonctions par rapport aux données).

3. L'APPROCHE SYSTEMIQUE (2ème GENERATION)

Les méthodes basées sur cette approche sont dites de 2ème génération (années 80).

Cette approche repose d’une part sur la modélisation des aspects statiques du problème (le domaine étudié) en présentant les concepts et informations du domaine, ainsi que leurs liens sémantiques. Le modèle Entité-Relation (ERD ou Entity-Relationship Diagram) de Chen est le modèle de base de toute modélisation statique.

Les aspects dynamiques du domaine sont modélisés par des réseaux de Pétri ou un formalisme dérivé faisant apparaître l’état de chaque donnée ainsi que les actions qui permettent les changements d’état.

Les apports récents à ces méthodes comme la spécification des contraintes entre entités et relations, les mécanismes d’héritage par généralisation-spécialisation, d’identification relative et de normalisation, ainsi qu’ils figurent dans Merise/2 de SEMA et Merise 2ème génération de CECIMA, préparent à l’effort d’abstraction nécessaire au passage à l’objet. Exemples : Merise, AXIAL, Information Engineering (James Martin)

Elles présentent les points forts suivants : ♦ une plus grande cohérence des données (bases de données non redondantes) ; ♦ un respect des niveaux de conception.

Cependant, Les points faibles suivants : ♦ un manque de cohérence entre modèles de données et de traitements (absence de règles

formelles de contrôle de la cohérence) ; ♦ une distinction des niveaux de conception différente selon les méthodes ; ♦ un mélange de la connaissance et du contrôle, dans la modélisation des traitements, en

présentant les règles de gestion et les contraintes d’intégrité dans une même logique algorithmique des fonctions du SI.



4. L'APPROCHE OBJET (3ème GENERATION)

Bien que reprenant des concepts anciens, les méthodes orientées objet constituent la 3ème génération (années 90).

L’approche objet peut être considérée comme une évolution de l’approche systémique en proposant une plus grande cohérence entre les objets et leur dynamique. L’association de la structure d’un objet à son comportement vise à offrir une meilleure modularité destinée à favoriser la réutilisation de composants du SI.

La principale contribution de l’objet est de décrire le SI comme un ensemble d’objets indépendants et en interaction, ce qui consiste à décomposer les problèmes à résoudre au niveau le plus fin, puis d’assembler des solutions élémentaires en vue de recomposer un système cohérent.

Exemples de méthodes orientées objet : OOA (Object Oriented Analysis de Shlaer et Mellor), OOD (OO Design de Booch), OOA/OOD (de Coad et Yourdon), HOOD (Hierarchical OOD de Delatte), OMT (Object Modelling Technique de Rumbaugh), OOSE (Object Oriented Software Engineering de Jacobson), OOM (Orientations Objets de Merise de Rochfeld)

La mise en commun des points des principales méthodes orientées objet a donné lieu à la création de UML (Unified Modeling Language), un langage de modélisation unifié destiné à constituer un socle commun de modélisation entre les différentes méthodes orientées objet, mais ne fournissant aucune indication quant à la démarche.

Les points forts des M.O.O. résident dans leurs capacités à modéliser des objets complexes, ce qui signifie que :

les distorsions entre le réel et le système informatique sont réduites ; ♦

♦

♦

la représentation de la dynamique des objets est facilitée ;

des traitements et des données dans les objets permettent de cacher les mécanismes d’implémentation et de mettre l’accent sur les services rendus.

Les points faibles sont ceux qui sont inhérents à une technologie "nouvelle", c'est-à-dire dans la tentation du "tout objet" conduisant à modéliser chaque concept ou fonction du SI comme un objet en tentant d’en interpréter le comportement.

Les règles de définition d’une entité dans l’approche systémique montrent pourtant que certains objets potentiels ne sont que les résultats d’un algorithme.

5. LES METHODOLOGIES "AGILES"

Les dernières années ont suscité un intérêt croissant pour les méthodologies "agiles", c'est à dire légères. Présentées comme un antidote à la "bureaucratie" des méthodologies existantes, elles ont soulevé un intérêt de la part de l'ensemble du paysage informatique.

Une méthode agile est une méthode de développement permettant de concevoir des logiciels en impliquant au maximum le demandeur (client), ce qui permet une grande réactivité à ses demandes.



Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles visent la satisfaction réelle du besoin du client, et non celle d'un contrat établi préalablement. La notion de méthode agile est née à travers un manifeste signé par 17 personnalités, créateurs de méthodes ou dirigeants de sociétés.

5.1. Les valeurs

Dans ce but, elles prônent 4 valeurs fondamentales (entre parenthèse, les citations du manifeste).

5.1.1. L'EQUIPE ("PERSONNES ET INTERACTION PLUTOT QUE PROCESSUS ET OUTILS")

Dans l'optique agile, l'équipe est bien plus importante que les moyens matériels ou les procédures. Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu'une équipe composée d'individualistes, même brillants. La communication est une notion fondamentale.

5.1.2. L'APPLICATION ("LOGICIEL FONCTIONNEL PLUTOT QUE DOCUMENTATION COMPLETE")

Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication).

5.1.3. LA COLLABORATION ("COLLABORATION AVEC LE CLIENT PLUTOT QUE NEGOCIATION DE CONTRAT")

Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un retour ("feed-back") continu sur l'adaptation du logiciel à ses attentes.

5.1.4. L'ACCEPTATION DU CHANGEMENT ("REAGIR AU CHANGEMENT PLUTOT QUE SUIVRE UN PLAN")

La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières versions ("releases") du logiciel vont souvent provoquer des demandes d'évolution.

5.2. Les principes

Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles : ♦ "Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels

utiles". ♦ "Le changement est bienvenu, même tardivement dans le développement. Les processus

agiles exploitent le changement comme avantage compétitif pour le client". ♦ "Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec

une tendance pour la période la plus courte". ♦ "Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet". ♦ "Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien

dont elles ont besoin, et croyez en leur capacité à faire le travail".



♦ "La méthode la plus efficace de transmettre l'information est une conversation en face à face". ♦ "Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet". ♦ "Les processus agiles promeuvent un rythme de développement soutenable. Sponsors,

développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment". ♦ "Une attention continue à l'excellence technique et à a qualité de la conception améliore

l'agilité". ♦ "La simplicité - l'art de maximiser la quantité de travail qu'il est inutile de faire - est essentielle". ♦ "Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-

organisent". ♦ "À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et

ajuste son comportement dans ce sens".

5.3. Les différentes méthodologies "agiles"

Plusieurs méthodologies sont rassemblées sous la bannière du développement agile. Elles ont toutes des caractéristiques en commun, mais il y a des différences significatives.

5.3.1. XP (EXTREME PROGRAMMING)

De toutes les méthodes agiles, c'est celle qui attire le plus d'attention. C'est grâce à la remarquable habilité des fondateurs de XP et à leurs talents publicitaires et managériaux que XP a attiré tant de monde. Par certains coté cependant, la popularité de XP est devenue un problème, en occultant les autres méthodologies agiles et leurs bonnes idées.

XP prend racine dans la communauté XP, et en particulier grâce à la collaboration étroite de leur fondateurs (Ken Beck et Ward Cunningham) dans les années 80. Tous deux ont redéfini leur manière de travailler au cours de nombreux projets dans les années 90, construisant leurs idées sur une approche de développement logiciel qui soit adaptative et orientée vers l'individu.

XP se fonde sur 4 valeurs : ♦ la communication ; ♦ le retour d'information ; ♦ la simplicité ; ♦ et le courage.

Il construit ensuite une douzaine de pratiques auxquelles les projets XP devraient se conformer. La plupart de ces pratiques sont anciennes, admises et testées, et pourtant oubliées par beaucoup, y compris dans les projets les plus planifiés. Outre la résurrection de ces pratiques, XP les assemble dans un ensemble cohérent et synergique, dans lequel chaque pratique est renforcée par les autres.

Un des cotés les plus percutants est l'accent mis sur le test. Alors que la plupart des processus évoquent le test, ils ne soulignent pas sont importance. XP met le test au cœur du développement, avec chaque développeur qui écrit les tests en même temps qu'il écrit le code source. Les tests sont intégrés dans un processus de compilation et d'intégration continue, qui tend à stabiliser une plate-forme pour les développements futurs.

Sur cette plate-forme, XP créé un processus de conception ("design") évolutif, qui s'appuie sur le 'refactoring' - la remise en cause perpétuelle de l'architecture et le "design" - d'un système de base à chaque itération. Tout le "design" est concentré sur l'itération en cours avec aucune anticipation pour des besoins futurs. Le résultat est un processus de "design" discipliné, et pourtant impressionnant car il combine la discipline et l'adaptabilité. De telle manière qu'il peut prétendre à la première place parmi les méthodes adaptatives.



5.3.2. LA FAMILLE DE METHODOLOGIES CRYSTAL

Fondée par Alistair Cockburn, cette approche méthodologique va au rebours de beaucoup de méthodologistes.

Les méthodes Crystal partagent avec XP l'orientation vers l'individu, mais le coté humain est abordé différemment. Alistair considère que les gens trouvent difficile de suivre un processus discipliné, donc plutôt que de leur faire suivre le rigoureux processus XP, Alistair explore les méthodologies les moins disciplinées qui pourraient encore marcher en favorisant la facilité d'exécution plutôt que la productivité. Il espère que, bien que Crystal soit moins productif que XP, plus de monde pourront l'utiliser.

Alistair met aussi beaucoup l'accent sur la revue à la fin de chaque itération, encourageant ainsi le processus à évoluer de lui-même. Son assertion est que le développement itératif est là pour trouver les problèmes en amont et permettre aux individus de les corriger. Ceci met donc l'accent sur la responsabilité des individus de suivre l'évolution de leur processus de travail dans le temps, et de le faire évoluer en fonction de leur expérience.

En Février 2001 Alistair a annoncé que Jim Highsmith (cf. § 5.3.4) et lui-même allaient fondre leurs deux méthodologies.

5.3.3. OPEN SOURCE

Si l'open source est un type de logiciel, son processus de développement induit une manière bien définie de travailler au sein de la communauté (open source). Une part importante de leur approche est applicable aux projets fermés autant qu'aux projets open source. En particulier leur processus est adapté aux équipes physiquement distribuées, ce qui est important dans la mesure où les autres processus adaptatifs mettent l'accent sur des équipes rapprochées.

La plupart des projets open source ont un ou plusieurs mainteneurs. Un mainteneur est une personne unique qui est autorisée à faire un changement dans le code source principal. Cependant beaucoup d'autres personnes peuvent soumettre des propositions de changements au mainteneur, qui les vérifie et les applique au code source principal. En général ces changements sont faits sous la forme de fichiers patch, ce qui facilite le processus. Le mainteneur est donc responsable de la coordination de ces changements et de maintenir la cohésion générale du logiciel, en terme de design.

Différents projets gèrent la question du mainteneur de différentes manières. Certains ont un mainteneur pour la totalité du projet, d'autres le divisent en modules séparés, d'autres font tourner le mainteneur, d'autres ont plusieurs mainteneurs pour le même code, d'autres font une combinaison de ces idées. La majorité des développeurs open source sont à temps partiel, ce qui pose un problème de qualité de coordination pour les projets à plein temps.

Un trait particulier du développement open source est que le débuguage est hautement parallélisable. Donc beaucoup de personnes peuvent s'impliquer dans le débuguage. Lorsqu'ils trouvent un bug, ils peuvent envoyer le patch au mainteneur. C'est un bon rôle pour les non-mainteneurs dans la mesure où énormément de temps est passé à trouver les bugs. C'est aussi une tâche acceptable pour les développeurs qui n'ont pas de compétence importante en design.

Le processus du monde open source n'est pas encore, à ce jour, formalisé (par écrit).

5.3.4. LE DEVELOPPEMENT ADAPTATIF DE LOGICIELS DE HIGHSMITH

Son fondateur, Jim Highsmith, se concentre sur la nature adaptative des nouvelles méthodologies, avec un accent plus particulièrement sur l'application des idées qui puisent dans les systèmes adaptatifs complexes (que l'on nomme communément la théorie du chaos). Il n'offre pas de manuel pratique détaillé comme dans XP, mais il fournit la base fondamentale pour comprendre le



besoin d'un processus de développement adaptatif, et ses conséquences au plus haut niveau notamment sur les plans de l'organisation et du management.

Au cœur d'ASD il y a trois phases non linéaires qui peuvent se chevaucher: la spéculation, la collaboration, et l'apprentissage.

Highsmith voit la planification comme un paradoxe dans l'environnement adaptatif, puisque les résultats sont par nature imprévisibles. En planification traditionnelle, les écarts par rapport au plan sont des erreurs qui doivent être corrigées. Dans un environnement adaptatif, cependant, les écarts nous guident vers la bonne solution.

Dans cet environnement imprévisible la collaboration efficace des personnes est indispensable pour s'accommoder de l'incertain. L'attention de la Direction doit se porter moins sur la dictée de ce que le gens doivent faire, que sur l'encouragement de la communication afin que les individus apportent eux-même des réponses créatives.

Dans les environnements prédictifs, l'apprentissage est souvent découragé. Vous posez des jalons en avance, puis vous suivez le plan.

"Dans un environnement adaptatif, l'apprentissage remet en question tous les intervenants - les développeurs et les utilisateurs - pour qu'ils examinent leurs supposition et qu'ils utilisent les résultats de chaque itération du cycle de développement pour adapter le cycle suivant" (Highsmith)

En tant que tel, l'apprentissage est un aspect important et continuel, on peut aussi supposer que les plans et le design change au fur et à mesure que le développement progresse.

"Le bénéfice prédominant, le plus puissant, indivisible et révolutionnaire, dans le Cycle de Développement Adaptatif, est qu'il nous force à confronter les modèles mentaux qui sont à la racine de notre mise en erreur. Il nous force à estimer de manière plus réaliste nos capacités" (Highsmith ).

En mettant l'accent sur ce point, le travail de Highsmith se concentre directement sur les points délicats du développement adaptatif, en particulier comment faire naître la collaboration et l'apprentissage collectif et individuel dans le projet.

5.3.5. SCRUM

Cela fait un moment que l'on croise SCRUM dans les cercles du développement orienté-objet. Cette méthodologie se concentre également sur le fait que les processus répétitifs et définis ne fonctionnent que pour s'attaquer à des problèmes répétitifs et définissables, avec des individus répétitifs et définissables, dans des environnements répétitifs et définissables.

SCRUM divise un projet en itérations (qu'il nomme des courses) de 30 jours. Avant de commencer une course vous définissez la fonctionnalité requise pour cette course et laissez l'équipe vous la livrer. Le point est de stabiliser les besoins pendant la course.

Cependant la Direction ne se désengage pas pendant la course. Chaque jour l'équipe échange l'information au cours d'une courte réunion de projet - appelée une "scrum" - au cours de laquelle on discute de ce qu'on va faire le lendemain. En particulier, on s'en tient aux aspects de la gestion de projet: ce qui empêche de progresser et que la Direction doit résoudre. On fait aussi un rapport de ce qui a été fait, si bien que la direction est au fait de l'avancement.

La littérature sur SCRUM se concentre principalement sur le processus itératif de suivi et de planification. Il est très proche de celui des autres méthodes agiles en général et devrait donc marcher, par exemple, avec les pratiques de codage de XP.



5.3.6. LE DEVELOPPEMENT ORIENTE-FONCTIONALITE DE COAD (FDD)

Le développement Orienté-Fonctionalité de Coad, ou encore FDD (Feature Driven Developpement) a été développé par Jeff de Luca et Peter Coad. Comme les autres méthodologies adaptatives, il se concentre sur des itérations courtes qui fournissent un résultat tangible sous la forme d'une fonctionnalité logicielle. Dans le cas de FDD, les itérations durent deux semaines. FDD a cinq processus. ♦ Développer un modèle général ; ♦ Construire une liste de fonctionnalités ; ♦ Planifier par fonctionnalité ; ♦ Designer par fonctionnalité ; ♦ Construire par fonctionnalité.

Les trois premiers sont réalisés en amont du projet. Les deux derniers sont réalisés pendant chaque itération. Chaque processus est décomposé en tâches et assigné des critères de vérification.

Les développeurs viennent sous deux formes distinctes : le propriétaire de classes et le programmeur en chef. Les programmeurs en chef sont les développeurs les plus expérimentés. Il leur est assigné des fonctionnalités, qu'ils doivent développer. Cependant ils ne les développent pas tout seuls. Au lieu de cela, le programmeur en chef identifie quelles classes sont impliquées dans le codage de la fonctionnalité et rassemble les propriétaires de ces classes pour former une équipe fonctionnelle, qui va développer cette fonctionnalité. Le programmeur en chef agit en tant que coordinateur, designer et mentor, tandis que les propriétaires de classes font le plus lourd du codage de la fonctionnalité.

5.3.7. METHODE DYNAMIQUE DE DEVELOPPEMENT DES SYSTEMES (DSDM)

DSDM s'est développé en Grande Bretagne en 1994 sous la forme d'un consortium de sociétés voulant construire sur le développement RAD (Développement Rapide) et itératif. En débutant avec 17 fondateurs il peut maintenant se targuer de plus d'un millier de membres et a grossi au delà de ses racines anglaises. Etant développé par un consortium, il se distingue des autres méthodes agiles de par sa nature. Il a une organisation à plein temps qui le supporte à l'aide de manuels, de cours de formation, de programmes d'accréditation, etc. Il a aussi un prix.

L'utilisation de cette méthode commence par une étude métier et une étude de faisabilité. L'étude de faisabilité considère si DSDM est approprié au projet en cours. L'étude métier est un série courte d'ateliers de travail pour comprendre les domaines métier concernés par le développement. Elles débouchent sur un diagramme haut niveau de l'architecture système et un plan de projet.

Le reste du processus forme trois cycles imbriqués : le cycle du modèle fonctionnel produit l'analyse de la documentation et des prototypes. Le cycle de conception ("design"), et le cycle de construction produit l'ingénierie du système en vue de l'utilisation opérationnelle, le cycle d'implémentation produit le déploiement pour l'utilisation opérationnelle.

DSDM a des principes sous-jacents qui incluent une interaction active avec l'utilisateur, des livraisons fréquentes, des équipes autonomes, du test tout au long du cycle. Comme d'autres méthodes agiles, elles utilisent des cycles distinct de 2 à 6 semaines. Il y a un accent marqué sur la qualité et l'adaptation aux changements de besoins.

Il n'y a pas beaucoup d'exemples d'utilisation de la méthode hors du Royaume-Uni, mais DSDL est remarquable pour son infrastructure, digne d'une méthode plus mature, tout en suivant les principes des méthodologies agiles.



5.3.8. THE AGILE ALLIANCE

Avec une telle similarité parmi ces méthodes, il y avait un intérêt manifeste pour une forme de travail collaboratif. Aussi, des représentants de chacune de ces méthodologies ont été conviés à un séminaire de deux jours à Snowbird Utah en Février 2001. Tout le monde était conscient qu'il y avait un terrain d'entente.

Aussi, outre la prise de contact utile entre les décideurs de différentes méthodologies, il y avait aussi l'idée de lancer un appel aux armes commun pour des processus de développement plus agiles.

Le résultat est un Manifeste pour le Développement Agile de Logiciels, un document à propos des valeurs communes et des principes des processus agiles. Il y a aussi un désir de collaborer plus loin dans le futur, pour encourager encore plus les ingénieurs et les responsables d'entreprises à utiliser et demander l'usage des méthodes agiles pour le développement logiciel.


La programmation

LA PROGRAMMATION

1. GENERALITES

Le traitement automatisé nécessite la mise en œuvre d'un (ou de plusieurs) programme(s). Mais avant cette mise en œuvre (mise en exploitation), il est nécessaire de concevoir le (ou les) programme(s).

La conception et l'écriture des programmes relèvent du domaine des techniques de programmation. Il existe plusieurs écoles de programmation, et notamment les 3 suivantes : ♦ La programmation linéaire : elle concerne les traitements dont le déroulement ne nécessite pas

l'intervention de l'utilisateur (traitement également appelé "en mode différé" ou "batch"). ♦ La programmation événementielle dont le déroulement nécessite l'intervention de l'utilisateur

(traitement également appelé en temps réel ou " en mode transactionnel"). ♦ Enfin la programmation orientée objet qui est une réponse aux besoins des nouvelles

applications graphiques, intégrées et évolutives.

2. LA PROGRAMMATION LINEAIRE

La programmation linéaire se déroule généralement en trois phases : ♦ Initialisation des variables (attente d’une entrée de paramètre au clavier), ouverture des

fichiers, préparation des variables de travail (internes au programme) ; ♦ les boucles du traitement : lecture d’enregistrement(s). Il s’ensuit le traitement des données de

(ou des) enregistrement(s), l'écriture du (ou des) enregistrement(s) dont les données ont été mise à jour par le traitement, l'impression éventuel de différent état d'édition. Il peut être fait appel à des procédures ou à des fonctions ;

♦ la fin du programme, qui consiste en une fermeture des fichiers et éventuellement à l'intention des services d'exploitation d'un affichage de message d'anomalie et de l'impression d'un bilan de passage.

Entre le début et la fin du programme, il y a linéarité du code : tout s’enchaîne selon l'ordre prévu lors de la conception du programme, y compris l’entrée des données par l’utilisateur. La séquence et le mode de ces entrées sont définis par le programmeur. En programmation linéaire, la conception d'un programme s'effectue principalement selon les 2 étapes successives suivantes :

1. L'élaboration d'un algorithme ;

2. L'écriture du code source dans le langage de programmation choisi.

L'élaboration d'un algorithme peur s'effectuer : ♦ sans méthode de construction : c'est la programmation dite "sauvage" ; ♦ ou à l'aide d'une méthode de conception : la programmation dite structurée.

La programmation structurée utilise des "briques de base" pour la construction de l'algorithme, qui porte le nom arbre programmatique. En programmation "sauvage", l'algorithme porte le nom d'organigramme.


La programmation

2.1. L’algorithmie

L’algorithmie est une technique permettant de décrire le "squelette" des traitements qui seront réalisés par le programme. Il prépare l'écriture du code source.

L'algorithme permet d’avoir une vue synthétique sur le déroulement de l'ensemble du traitement en soulignant, notamment, les interruptions de boucles, les fins de fichiers, les cas d’erreurs, les divers cas de figure envisagés (cas généraux, cas particuliers).

2.1.1. LES COMPOSANTS D’UN ORGANIGRAMME Pour construire un organigramme, vous disposez des symboles suivants :

Symbole général "traitement"

Symbole de la "condition"

2.1.2. L’ARBRE PROGRAMMATIQUE

L’arbre programmatique permet une représentation plus structurée que l’organigramme. La lecture d’un arbre s’effectue de gauche à droite et de haut en bas.

L’élément de base du traitement est le bloc, symbolisé par un rectangle :

Nom du bloc ou du module

EXPRESSION DE LA MODULARITE Chaque traitement possède un seul point d’entrée et un seul point de sortie. Si un bloc est exécuté, il est exécuté en entier. Ainsi, Traitement1 comprend trois traitements (Traitement1-1, Traitement1-2, Traitement1-3)

Traitement1-3 Traitement1-1 Traitement1-2

Traitement1


La programmation

2.1.3. LES STRUCTURES D'UN ALGORITHME

La structure d’un algorithme fait généralement appel à la combinaison de trois structures fondamentales utilisées en programmation : - la structure séquentielle ou enchaînement ; - la structure conditionnelle ou alternative ; - la structure répétitive ou itérative. L’ENCHAINEMENT

ARBRE PROGRAMMATIQUE ORGANIGRAMME PSEUDO CODE

Action1

Trt-A

Action 1

Trt-A Action 1

Trt-A

On exécute l’action 1 avant le traitement A (Trt-A).

L’ALTERNATIVE1ERE FORME : SI ALORS SINON


Si condition

Alors

BLOC ALORS

Sinon

BLOC SINON

Finsi

SI ALORS SINON

Condition simple ou complexe

non Condition oui non

BLOC ALORS BLOC SINON

oui BLOC SINON

BLOC ALORS

L’ALTERNATIVE 2EME FORME : ALTERNATIVE SIMPLE SI ALORS


La programmation

Il n’y a pas de BLOC SINON lorsque la condition n’est pas vérifiée. On passe au bloc d’instructions suivant..

L’ALTERNATIVE 3EME FORME : LE CHOIX MULTIPLE


Selon valeur

Val1 :

BLOC 1

Val2 :

BLOC 2

Autres :

BLOC SINON

Finselon

oui

non

oui

BLOC 1

BLOC SINON

non

Val2

BLOC 2

Val1 SELON

Valeur ou expression

Val1 Val2 autres

BLOC 1 BLOC 2 BLOC

LA REPETITIVE : 1ERE FORME : TANT QUE


TANT QUE condition

faire BLOC

FINTANTQUE

TANT QUE

Condition simple ou complexe condition

ouiBLOC ITERE

BLOC

Le test précède la boucle. Donc la boucle peut ne pas être exécutée. Le bloc sera donc exécuté de 0 à n fois


La programmation

LA REPETITIVE : 2EME FORME : FAIRE JUSQU’A


FAIRE JUSQU'A condition

faire BLOC

FINTANTQUE

FAIRE JUSQU’A

Condition simple ou complexe BLOC

BLOC ITERE condition

oui

Le test suit la boucle. Celle-ci est donc exécutée au moins une fois. Le bloc sera donc exécuté de 1 à n fois. Remarque : « TANT QUE » est préférable à « FAIRE JUSQU'A ». Il permet d’éviter les exécutions

aberrantes. LA REPETITIVE : 3EME FORME : POUR


POUR Indice DE I-début A i-fin PAS I-pas

faire BLOC

FINPOUR

POURIndice i-début

Indice DE i-début A i-fin PAS i-pas

Indice > i-fin

BLOC ITERE

non

BLOC

Indice Indice + i-pas

Indice : variable pour l’itération i-début : variable initiale de la valeur de l’indice i-fin : variable final de la valeur de l’indice i-pas : variable représentant le pas (facultatif, positif ou négatif) La variable indice ne doit pas être modifiée en dehors de l’incrémentation.


La programmation

2.2. L'écriture du code source

2.2.1. LE PSEUDO-CODE

Le pseudo-code est un langage de description des structures de données et des algorithmes. Proche du langage naturel, le pseudo-code est très facile à transcrire dans un langage de programmation cible. La présentation de la logique est moins visuelle qu’avec un organigramme ou un arbre programmatique mais offre des possibilités d’adaptation très appréciées (pas besoin de tracer des figures ou des tableaux).

Il convient de noter qu’il est possible de s’inspirer du pseudo-code pour simuler un exercice de programmation lorsque l’on ne maîtrise pas suffisamment un langage de programmation sur le plan de la syntaxe.

Il est conseillé de préférer l’indentation à une écriture de chaque ligne en début de colonne. L’indentation doit permettre de faire apparaître l’approche descendante nécessaire à toute programmation structurée : à chaque ‘DÉBUT’ doit correspondre un ‘FIN’, à chaque ‘SI’ doit correspondre un ‘FINSI’ et éventuellement un ‘SINON’…

L’aspect visuel du pseudo-code met en évidence l’architecture du programme, sa décomposition en modules. Un module est une suite d’instructions réalisant une fonction bien particulière.

On écrit en lettres majuscules les mots réservés au langage. Exemple :

DÉBUT

LECTURE agent

TANT QUE pas fin de fichier FAIRE

SI Note > 16 ALORS Prime = 10000

SINON

SI Note > 15 ALORS Prime = 7500

SINON Prime = 5000

FINSI

ÉCRIRE FicPrimes

FIN TANT QUE

Édition

FIN

2.2.2. L'ECRITURE DU CODE SOURCE

A partir de l'algorithme, le code source est écrit dans le langage choisi à l'aide d'un logiciel de traitement de texte spécifique (appelé "éditeur").


La programmation

3. LA PROGRAMMATION EVENEMENTIELLE

La programmation linéaire se prête difficilement au développement d’applications graphiques, du fait du grand nombre de choix d’actions offerts à l’utilisateur : tous les cas ne peuvent être prévus.

3.1. Les interfaces graphiques

Avec l’augmentation du parc de micro-ordinateurs, le nombre d’utilisateurs de l’informatique a considérablement augmenté. Cette généralisation a nécessité une évolution de l’ergonomie des logiciels. Les outils de communication directe (le clavier, la souris, l’interface graphique…) ont permis aux utilisateurs un nouveau type d’interaction avec l’ordinateur basé non plus sur des questions/réponses ou sur des menus mais sur une métaphore de l’univers quotidien (fenêtre, ascenseurs, dossier, bureau, calculette, copier, coller, déplacer-glisser…) représenté par des icônes. La réalisation d’une telle interface fait largement appel aux technologies objet.

Ce sont les interfaces graphiques qui symbolisent le mieux les concepts d’encapsulation et de comportement dynamique. Les compilateurs fournissent des hiérarchies d’objets et les concepts objets y sont utilisés tout au long du développement.

Les applications à interface graphique permettent aux utilisateurs de contrôler la manière dont ils fournissent les informations. Il s’agit d’applications événementielles. La programmation événementielle est adaptée à l’écriture d’applications graphiques : elle est constituée d’un ensemble de procédures indépendantes les unes des autres. Chaque procédure est écrite soit pour réagir à un événement, soit pour être appelée par une autre.

Un événement peut être : ♦ un clic de souris : sur une icône, sur un bouton de contrôle, sur une zone de menu... ♦ la frappe d’un texte au clavier dans un champ prédéfini ; ♦ l’utilisation d’une touche de fonction ; ♦ la combinaison de plusieurs événements (clic de la souris sur une zone et lâcher sur une

autre..).

Afin qu’il y ait une action, il faut écrire une procédure pour l’événement. La tendance de la programmation événementielle est d’utiliser de plus en plus la technique objet (Visual Basic, C, Delphi...).

3.2. Comparaison programmation structurée et programmation événementielle

PROGRAMMATION STRUCTUREE PROGRAMMATION EVENEMENTIELLE Mono-tâche Multitâches Environnement caractère Environnement graphique Le programmeur contrôle l’environnement Le système graphique contrôle l’environnement Le programmeur contrôle le déclenchement des tâches

L’utilisateur contrôle le déclenchement des tâches


La programmation

4. LA PROGRAMMATION ORIENTEE OBJET

4.1. Introduction

L’orientation objet correspond à une démarche naturelle de la modélisation où l’esprit commence par percevoir l’objet dans son individualité, puis il identifie ses fonctions, détaille sa structure et son comportement. Ensuite, il procède par analogie en généralisant ou en spécialisant.

L’objet est une réponse aux besoins des nouvelles applications graphiques, intégrées et évolutives. Elle est adaptée aux nouvelles architectures distribuées et ouvertes. De plus, la croissance exponentielle de la puissance des plates-formes matérielles ne trouve pas son équivalent dans les évolutions des langages dits structurés (Fortran, Cobol, etc).

La programmation orientée objet (POO) a permis de concevoir un système en tant que jeu d’objets collaborant les uns avec les autres. Les classes ont permis de cacher les détails d’implémentation au dessous des interfaces. Le polymorphisme a donné un comportement et une interface communs aux concepts liés, et a permis une meilleure spécialisation des composants, pour changer un comportement particulier sans pour autant devoir accéder à l’implémentation de base.

4.2. Définition et Caractéristiques

De manière superficielle, le terme "orienté objet" signifie que l'on organise le logiciel comme une collection d'objets dissociés comprenant à la fois une structure de données et un comportement, à la différence d'une programmation conventionnelle dans laquelle les structure de données et le comportement ne sont que faiblement associés.

4.2.1. IDENTITE

L'identité signifie que les données sont quantifiées en entités discrètes, que nous pouvons distinguer et que nous nommons objets. Un paragraphe dans un document, une fenêtre sur une station de travail, etc. Les objets peuvent être concrets, tel un fichier dans un système de fichiers, ou conceptuels comme une politique d’ordonnancement dans un système d'exploitation multitâche. Chaque objet possède sa propre identité. En d'autres termes, deux objets sont distincts même si tous leurs attributs (nom et taille par exemple) ont des valeurs identiques.

Dans le monde réel, un objet se contente d'exister, mais dans un langage de programmation chaque objet possède une clé unique par laquelle il peut être référencé sans ambiguïté. La clé peut être implémenté de diverses façons: une adresse, un indice dans un tableau ou une valeur unique d'un attribut. Les références sur les objets sont uniformes et indépendantes du contenu des objets, permettant ainsi la création de collection d'objets, telles qu'un répertoire de fichiers contenant à la fois de fichiers et des répertoires.

4.2.2. CLASSIFICATION

La classification signifie que des objets ayant la même structure de données (attributs) et le même comportement (opérations) sont regroupées en une classe. Paragraphe et fenêtre sont des exemples de classes. Une classe est une abstraction qui décrit les propriétés pertinentes pour l'application et ignore les autres. Tout choix de classes est arbitraire et dépend de l’application.

Chaque classe décrit un ensemble, pouvant être infini, d'objets individuels. Chaque objet est dit instance de sa classe. Chaque instance de la classe possède ses propres valeurs pour chaque attribut mais partage noms d'attributs et opérations avec les autres instances de la classe. Un objet contient une référence implicite à sa propre classe.


La programmation

4.2.3. POLYMORPHISME

Le polymorphisme signifie que la même opération peut se comporter différemment sur différentes classes. L'opération déplacer, par exemple, peut se comporter différemment sur les classes fenêtre et pièce de jeu d'échec.

Une opération est une action ou une transformation qu'un objet effectue ou subit. L'implémentation spécifique d'une opération par une certaine classe est appelée méthode. Parce qu'un opérateur orienté objet est polymorphe, il peut être implémenté par plus d'une méthode. Dans le monde réel, une opération est simplement une abstraction de comportements analogues parmi différents types d'objets. Chaque objet "sait comment" effectuer ses propres opérations. Cependant, dans un langage de programmation orienté objet, le langage sélectionne automatiquement la méthode correcte pour implémenter l'opération en se basant sur le nom de l'opération et sur la classe de l'objet sur lequel il opère. L’utilisateur d'une opération n'a pas besoin de connaître le nombre de méthodes existantes pour implémenter une opération polymorphe. De nouvelles classes peuvent être ajoutées sans modifier le code existant, pourvu que des méthodes soient fournies pour chaque opération applicable sur les nouvelles classes.

4.2.4. HERITAGE

L'héritage est le partage des attributs et des opérations entre des classes s'appuyant sur une relation hiérarchique. Une classe peut être définie à grands traits et ensuite raffinée dans les sous-classes de plus en plus fines. Chaque sous-classe incorpore, ou hérite, toutes les propriétés de sa super classe et y ajoute ses propres et uniques propriétés. Les propriétés de la super classe n'ont pas besoin d'être répétées dans chaque sous-classe. Par exemple, fenêtre déroulante et fenêtre fixe sont des sous-classes fenêtre.

La possibilité de factoriser des propriétés communes à plusieurs classes dans une super classe commune et d'hériter les propriétés de la super classe peut réduire de façon significative les répétitions dans la conception et dans les programmes. C’est l'un des principaux avantages d'un système orienté objet.

4.2.5. ENCAPSULATION

L'encapsulation signifie "ne me dites pas comment vous le faites, faites-le". C'est ce que fait l'objet en gérant ses propres ressources et en limitant sa visibilité à ce que les autres ont à savoir. Un objet fait connaître une interface publique qui définit comment d'autres objets ou applications peuvent dialoguer avec lui. Un objet a un composant privé qui implémente les méthodes. L'implémentation de l'objet est encapsulé, c'est à dire cachée à la vue publique. Les données d'instance peuvent être déclarés privées, ce qui est par défaut le cas habituel, ou publiques. Les données d'instance privées ne sont accessibles que par les méthodes de la classe.

Par contre, les données d’instance publiques font partie de l’interface externe publiée. Les méthodes et les données d'instance publiques constituent l'interface permanente entre l'objet et le monde extérieur.

4.3. Conclusion

Chaque programme est conçu comme un ensemble d’objets autonomes qui interagissent entre eux. Lorsqu’elles sont bien conçues, les bibliothèques d’objets sont facilement réutilisables.

Elles permettent une organisation dans le programme qui facilite grandement le développement d’applications ainsi que les développements faisant intervenir de nombreux programmeurs.


La programmation

Assimiler les concepts de la programmation objet n’est pas chose évidente mais le programmeur ne tarde pas à en tirer un certain nombre de bénéfices.

5. LA PROGRAMMATION ORIENTEE ASPECT

Actuellement, la programmation orientée objet (POO) est la méthodologie de choix pour la plupart des nouveaux projets de développement. En fait, la POO a montré sa force lorsqu’il s’agit de modéliser des comportements communs.

Cependant, comme nous allons le voir par la suite, la POO ne permet pas de modéliser de manière adéquate des comportements qui s’étalent sur plusieurs modules, souvent sans aucun rapport. C’est cette lacune que tente de combler la POA (Programmation Orientée Aspect). La POA représente peut-être la prochaine grande étape en matière d’évolution des méthodologies de programmation.

5.1. Présentation de la POA (Programmation Orientée Aspect)

La POA facilite la modularisation des problématiques qui se recoupent et permet la création de systèmes logiciels plus simples à modéliser et à faire évoluer. Apres la programmation orientée objet, la programmation orientée aspect pourrait bien représenter la prochaine grande étape en matière de méthodologie de développement.

La plupart des systèmes logiciels consistent en problématiques multiples qui traversent de multiples modules. Les techniques de programmation orientée objet visant à implémenter de telles problématiques créent des systèmes envahissants à programmer, complexes à comprendre et difficiles à faire évoluer.

La nouvelle méthodologie de programmation orienté aspect (POA) facilite la modularisation des problématiques de recouvrement, la création des implémentations plus faciles à modéliser, à comprendre et à maintenir. De plus, la POA promet une meilleure productivité, une meilleure qualité et une plus grande facilité pour implémenter de nouvelles fonctionnalités.

5.2. Visualiser un système comme une suite de problèmes

On peut voir un système logiciel complexe comme une implémentation combinée de plusieurs problèmes. Un système typique peut consister en différents aspects, incluant les règles métier, la performance, la persistance des données, la journalisation des activités, le débogage, l’authentification, la sécurité, la solidité du multithreading, la gestion des erreurs, etc. On est également confronté à des problématiques de développement comme la compréhensibilité, la maintenabilité, la traçabilité et l’évolutivité.

Une problématique est un but particulier, un concept ou un centre d’intérêt.

En termes techniques, un système logiciel typique comporte plusieurs fondamentaux, et plusieurs niveaux de problématiques.


La programmation

Par exemple, le fondamental d’un système d’un centre de paiement par cartes bancaires s’occupera des paiements, alors que les problématiques au niveau du système s’occuperont du "login", de l’intégrité des transactions, de l’authentification, de la sécurité et des performances.

La plupart de ces problématiques, qui se recoupent pour certaines, tendent à affecter plusieurs modules. En utilisant les méthodologies de programmation traditionnelles, les problèmes de recoupements concernent plusieurs modules, il en résulte en un système complexe à modéliser, à comprendre, à implémenter et à faire évoluer.

La programmation orienté aspect offre une meilleure séparation des problématiques que les méthodologies précédentes. Elle permet entre autres la modularisation de problématiques qui se recoupent.

5.3. Le recoupement des problématiques et la problématique des recoupements

Un développeur crée un système comme une réponse à des besoins multiples. On peut les classifier, de manière large, sous forme de besoins au niveau du fondamental, et des besoins au niveau du système.

La plupart des besoins au niveau du système tendent à être orthogonaux (c’est-à-dire mutuellement indépendants) les uns par rapport aux autres, et par rapport aux besoins au niveau des modules.

Par exemple, une application typique d’entreprise comprend un certain nombre de problématiques qui se recoupent, comme l’authentification, le "login", la gestion des ressources, l’administration, les performances et la gestion du stockage. Chacun de ses aspects recoupe plusieurs sous-systèmes.

Bien que les recoupements concernent des modules multiples, les techniques d’implémentation actuelles tendent à implémenter ces problèmes en utilisant une méthodologie unidimensionnelle, forçant l’implémentation de l’organisation des besoins à une seule dimension. Cette dimension unique tend à être l’implémentation du module au niveau fondamental.

Le reste des besoins est lié à cette dimension dominante. En d’autres termes, l’espace des besoins est à n dimensions alors que l’espace d’implémentation est à une dimension. Une telle erreur conduit à des erreurs dans la modélisation besoin-implémentation.

5.3.1. SYMPTOMES

Quelques symptômes peuvent indiquer une implémentation problématique de recoupements en utilisant les méthodologies actuelles. On peut classifier ces symptômes en deux catégories : ♦ Emmêlement de code

Les modules d’un système logiciel peuvent interagir de manière simultanée avec plusieurs contraintes. Par exemple, il est fréquent que les développeurs pensent simultanément à la logique à implémenter, aux performances, à la synchronisation et à la sécurité. Une telle multitude de contraintes conduit à la présence simultanée d’éléments de chaque implémentation dans les modules, résultant un emmêlement du code.

♦ Eparpillement du code Comme les problèmes de recoupement, par définition, concernent plusieurs modules, leurs implémentations sont elles aussi disséminées au travers de ces modules. Par exemple, dans un système utilisant une base de données, les problèmes de performances peuvent affecter tous les modules qui accèdent à la base.


La programmation

5.3.2. IMPLICATIONS

Combinées, l’emmêlement et l’éparpillement du code affectent la modélisation logicielle et le développement de nombreuses façons : ♦ Mauvaise traçabilité

L’implémentation simultanée de multiples contraintes rend obscure la correspondance entre une contrainte et son implémentation.

♦ Faible productivité L’implémentation simultanée de plusieurs contraintes éloigne la concentration du développeur du but final, vers les contraintes annexes, limitant d’autant la productivité.

♦ Plus faible réutilisation du code Etant donnée qu’en ces circonstances, un module implémente des contraintes multiples, les autres systèmes qui nécessitent des fonctionnalités similaires ne sont pas forcément capables d’utiliser directement le module, diminuant également la productivité.

♦ Pauvre qualité du code L’emmêlement du code produit souvent un code disposant de problèmes cachés. De plus, en ciblant trop de contraintes en même temps, une ou plusieurs de ces contraintes ne recevront pas toutes l’attention nécessaire.

♦ Evolution difficile Une vue limitée, et des ressources limitées produisent généralement un modèle qui ne répond qu’aux problèmes actuels. Répondre aux problèmes futurs nécessite souvent de retravailler toute l’implémentation. Et comme l’implémentation n’est pas modularisée, il est nécessaire de modifier de nombreux modules. Mais aménager chaque sous-système pour répercuter les modifications peut conduire à des incohérences. Cela requiert également des efforts considérables au niveau des tests pour s’assurer que de tels changements n’ont pas provoquer des bugs.

5.4. Les fondements de la POA

La POA permet de modulariser l’implémentation des problématiques qui se recoupent, avec pour but principal de pouvoir séparer les besoins. La POA aspire à pouvoir séparer clairement les besoins pour répondre aux problèmes que nous avons évoqués précédemment.

La POA, en son cœur, permet d’implémenter des problématiques individuelles de manière libre, pour combiner ces implémentations afin de former le système final. En fait, la POA crée un système à partir d’implémentations de modules qui se recoupent, au contraire de la POO qui crée un système à partir d’implémentations de modules communs.

Une unité de modularisation en POA est appelée aspect, tout comme une implémentation d’un besoin commun en POO est appelée classe. La POA nécessite trois étapes de développement : ♦ La décomposition des aspects

Décomposer les besoins pour identifier les besoins communs et ceux qui se recoupent. Par exemple, dans l’exemple du centre de traitement de cartes bancaires, on identifiera trois besoins : la gestion des cartes bancaires, le log des activités, et l’authentification.

♦ Implémentation des besoins On implémente chaque besoin de manière séparée. Toujours dans le même exemple, on implémente séparément la gestion des cartes bancaires, le log des activités et l’authentification.


La programmation

♦ La recomposition en fonction des aspects Dans cette étape, on spécifie les règles de recomposition en créant les unités de modularisation, les aspects. Le processus de recomposition, également désigné par le nom d’intégration ou de tramage, utilise ces informations de pour créer l’implémentation POA. Dans notre exemple, on spécifiera, dans un langage fourni par l’implémentation POA, que chaque début et fin d’opération devra être journalisé. On spécifiera également que chacune des opérations devra passer au travers de l’authentification avant de pouvoir attaquer la logique principale.

La POA diffère grandement de la POO dans la manière dont elle gère les problèmes de recoupements. Avec la POA, chaque unité implémentée reste inconsciente du fait que les autres unités peuvent l’instancier en tant qu’aspect.

Par exemple, le module de gestion de carte bancaire ne sait pas que les autres unités journalisent et authentifient ses opérations. Cela représente un très fort changement de paradigme par rapport à la POO.

Une implémentation POA peut employer une autre méthodologie de programmation en tant que méthodologie de base, ce qui permet de cumuler les bénéfices des deux approches. Par exemple, une implémentation POA peut choisir la POO comme système de base pour profiter des bénéfices d’une meilleure implémentation des besoins communs au travers de la POO. Avec une telle implémentation, les besoins individuels peuvent employer les techniques de POO pour chaque besoin identifié. C’est analogue au fait d’utiliser un langage procédural comme base pour un langage orienté objet (C et C++ par exemple).

5.5. Les bénéfices de la POA

La POA permet de répondre aux problèmes susmentionnés causés par la dispersion et l’emmêlement du code, à savoir : ♦ Implémentation modularisée des problèmes de recoupement

La POA répond à chaque problématique de manière séparée, en minimisant les interactions. Il en résulte en une implémentation modulaire même pour un modèle fortement recoupant.

♦ Des systèmes plus faciles à faire évoluer Comme les modules aspects ne sont pas au fait des problèmes de recoupement, il est beaucoup plus facile d’ajouter de nouvelle fonctionnalités en créant de nouveaux aspects. De plus, l'ajout de nouveaux modules à un système aide à créer une évolution cohérente, les aspects existants les recoupant..

♦ Repousser les décisions de modélisation Avec la POA, la prise de décision pour des besoins futurs peut être eeportée, du fait qu’il sera possible de les implémenter sous forme d’aspects séparés.

♦ Une plus grande réutilisation du code Etant donné que la POA implémente chaque besoin en tant que module séparé, cela réduit d’autant les liens entre les modules. En règle générale, moins les modules sont liés, plus le code est réutilisable. La POA permet de réaliser des implémentations moins liées qu’en POO.

5.6. Implémentation du langage POA

AspectJ, développée par Xerox PARC, est un langage (gratuite) orienté aspect pour Java.


La programmation

AspectJ utilise le langage Java pour implémenter les besoins individuels, et spécifie une extension de Java pour les règles de tramages. Ces règles sont spécifiées en termes de "pointcuts", "join points", "advice" et aspects : ♦ les "join points" définissent des points spécifiques dans l’exécution d’un programme ; ♦ le pointcut est le constructeur de langage qui permet de spécifier les "join points" ; ♦ et "advice" définit les portions d’un aspect qui doivent être exécutées lors de "pointcuts".

Un aspect combine ces trois primitives.

En prime, AspectJ autorise également "d’aspecter" des aspects et des classes de différentes manières.

Concrètement, il est possible d’introduire de nouvelles données membres et de nouvelles méthodes, tout comme on peut déclarer qu’une classe implémente d’autres classes additionnelles ou d’autres interfaces.

"L’AspectJ weaver" est un compilateur aspect qui combine ensemble les différents aspects. AspectJ comporte un certain nombre d’outils tel qu'un débogueur et une intégration aux environnements de développement.


Les langages de programmation

LES LANGAGES DE PROGRAMMATION L'idée des langages de programmation est aussi vieille que celle du calculateur digital.

Il suffit de programmer un ordinateur directement en code binaire pour comprendre immédiatement pourquoi.

Les premiers programmeurs ont donc rapidement inventé des notations symboliques appelées "langage" traduites en code binaire par des programmes appelés "compilateur".

Parmi les premiers langages, celui dont l'influence a été la plus grande est sans nul doute le FORTRAN développé entre 1954 et 1957 par John Backus et ses collègues chez IBM. Il n'était pas sûr qu'à une époque où la puissance des machines était très limitée, un compilateur puisse produire du code efficace. Cet objectif avait été atteint et FORTRAN est encore utilisé aujourd'hui.

Cependant, la version originale de FORTRAN comportait des contraintes inutiles, des structures de données limitées et surtout de sérieuses déficiences dans le contrôle de la logique du programme. Dans un certain sens, on peut dire que toutes les recherches dans la définition de nouveaux langages de programmation ont été motivées par des essais de correction des défauts du FORTRAN.

Que les langages aient été définis par un Comité comme COBOL, une organisation commerciale comme PL/I, un individu comme PASCAL ou par le Ministère de la Défense américain comme ADA, toutes les tentatives de définir le langage universel ont échoué, laissant la voie libre à des milliers de langages dont seulement une petite dizaine est largement répandue.

1. GENERALITES

Un programme informatique est une succession d’instructions exécutable par l’ordinateur. Toutefois, au niveau élémentaire (circuits de calcul, mémoire centrale), l’ordinateur ne manipule que de l'information (instruction et données) binaire, représentée par une succession de "0" et de "1". De ce fait, on dit qu'un programme exécutable par le processeur est en "langage machine".

Les premiers programmes étaient écrits directement en langage binaire, tâches d'écriture qui se sont révélées très rapidement fastidieuses. Les langages de programmation ont ainsi été créée afin : ♦ de rendre l'écriture des programmes moins fastidieuse et d'en faciliter leurs écritures ; ♦ de favoriser leurs lisibilités sous une forme plus directement compréhensible par l’homme ; ♦ de faciliter l'écriture de programme complexe (et donc volumineux) ; ♦ de rendre transparente les tâches de gestions élémentaires des données et des instructions

(résolutions d'adresse mémoire notamment).

La façon d’écrire un programme est liée au langage de programmation que l’on a choisi.

L'opération de traduction est effectuée par un logiciel spécialisé (appelé compilateur ou interpréteur) qui correspond spécifiquement : ♦ au langage choisi ; ♦ et au processeur qui exécutera la traduction binaire du programme.



Attention

Quel que soit le langage de programmation, son utilisation s'accompagne toujours d'une opération de traduction (en langage machine) afin de rendre le programme directement compréhensible par la machine.

Un langage de programmation se compose : ♦ d'un jeu d'instructions nécessaires à la formalisation des traitements à exécuter :

• des instructions d’entrée-sortie ; • des instructions de calcul : addition, soustraction, multiplication et division ; • des instructions logiques pour formaliser des conditions et des actions : ET, OU, PAS, etc. • des instructions de mouvement, de recherche et d'emmagasinage de données.

♦ de règles syntaxiques qui définissent l'écriture de ces instructions avec les données manipulées ;

♦ de règles d'écriture des données (structure, variable, …).

A un langage de programmation est associé un logiciel de traduction (compilateur ou interpréteur).

2. LES GENERATIONS DE LANGAGE

Dans les débuts de l’informatique, les programmeurs écrivaient des programmes en codant directement en langage machine. Malheureusement, ils passaient plus de temps à étudier un langage machine particulier qu’à résoudre des problèmes.

Progressivement sont apparus des langages de plus haut niveau, qui nous ont offert une certaine abstraction vis-à-vis de l’architecture de la machine. Puis vinrent les langages structurés : on pouvait désormais décomposer les problèmes sous forme de procédures nécessaires à la réalisation d’une tâche.

Depuis 1946, les langages de programmation ont connu une évolution continue qui les ont rapprochée de plus en plus du langage humain. On parle de langages de programmation de "haut niveau".

Mais cette évolution n'a été possible qu'au prix d'une complexité croissante, consommatrice de ressources machines suffisante (processeur et mémoire).

De ce fait, l'apparition progressive de langages de haut niveau a été tributaire des progrès de la miniaturisation des composants (augmentation des capacités de traitement et de mémoire).

Pour chaque catégorie de problèmes, il est possible de créer un langage adapté à l'aide duquel les-dits problèmes trouveront un exposé clair. Et l'on sait qu'un problème bien posé est à moitié résolu ...

Pour les langages de programmation, les débuts ont été très difficiles. Il fallait permettre à la machine de faire exactement ce que le programmeur voulait. Pour ne pas trahir la pensée du programmeur, il a fallu la structurer, l'exprimer sans ambiguïté, la traduire en séquences intelligibles par le processeur ... Les langages se sont peu à peu sophistiqués, optimisés, rationalisés et démocratisés.



Les langages définissent la manière dont nous communiquons avec les machines. Chaque nouvelle méthodologie présente de nouvelles manières de décomposer les problèmes, le code machine, le code indépendant de la machine, les procédures, les classes, etc. L’évolution de ces méthodologies de programmation ont permis de créer des systèmes à la complexité toujours plus élevée.

Avec l’augmentation de la complexité, de nouvelles techniques devenaient nécessaires.

La réciproque est également vraie, l’existence de ces systèmes toujours plus complexes est possible parce que ces nouvelles techniques ont permis d’appréhender leur complexité.

Remarque :

La simplicité apportée au développeur (dans l'écriture du programme) par un langage de haut niveau s'est traduit par une complexité croissante des logiciels de traduction (et des systèmes d'exploitation) associés.

2.1. Les langages de 1ere génération (L1G)

Le langage machine est le seul langage directement compréhensible par la machine. C'est le plus bas niveau de langage de programmation.

Son avantage principal résidait dans l'efficacité des programmes écrits directement en langage machine. Mais les erreurs de transcription étaient fréquentes et la tâche fastidieuse. Il fallait en outre que le programmeur mémorise les nombres de chaque code utilisé et garde trace des instructions et des adresses où elles devaient s'exécuter.

Programmer en langage-machine était donc une opération coûteuse parce que très longue et la correction des erreurs n'en finissait plus. Il était aussi très compliqué de modifier les programmes après coup.

2.2. Les langages de 2ème génération (L2G)

Pour alléger les difficultés de programmation en langage-machine, on imagina au début des années 1950, une notation symbolique formée de mnémoniques (pour représenter les instructions à donner à la machine et des adresses symboliques pour localiser les casiers de la mémoire de l’ordinateur.

L'assembleur (1) est le premier langage informatique qui ait été utilisé (ils est aussi appelé "langage mnémonique"). L'assembleur est très proche du langage machine (il est appelé pour cela langage de bas niveau) mais il permet déjà d'être plus compréhensible.

Un mnémonique est petite séquence alphabétique simple à retenir. Ainsi, dans un processeur, nous avons des registres qui permettent la manipulation de données. Pour ajouter deux registres, les différents langages assembleur (chaque processeur ayant son propre langage machine et donc son propre assembleur) définissent souvent un mnémonique add, par exemple :

ADD bx, 4 Addition dans un registre CMP [adr], 3 Comparaison avec une variableJMP address Saut à une adresse



Chaque microprocesseur autour duquel il est construit possède son propre langage assembleur.

On économise un certain temps (facilité d'écriture et de maintenance) mais les programmes ainsi écrits sont peu transportables d’un microprocesseur à l’autre. Car un tel langage est tellement proche du langage machine qu'il dépend étroitement du type de processeur utilisé (jeu d'instruction machine propre au processeur). Ainsi un programme développé pour une machine ne pourra pas être porté (2) sur un autre type de machine. Pour pouvoir l'utiliser sur une autre machine il faudra alors parfois réécrire entièrement le programme.

Pour transformer un programme assembleur en langage machine, on utilise un logiciel appelé assembleur. Réciproquement, on génère un code assembleur à partir d'un programme en langage machine via un désassembleur.

La programmation en assembleur ne se pratique plus que très rarement sur les ordinateurs actuels.

Remarque :

(1) Autre langage de 2ème génération, l'Autocodeur crée en 1952.

(2) La portabilité désigne la "capacité" d'un même programme d'être utilisé (tel quel) par d'autre processeur que celui d'origine.


Les langages de troisième génération (dits "langages évolués" ou également "de haut niveau") sont des langages informatiques offrant un certain niveau d’abstraction par rapport au langage machine, et manipulant des structures syntaxiques telles que les déclarations, les instructions de contrôle, etc. Usuellement, le terme "évolué" désigne tout langage de niveau supérieur à celui du langage assembleur.

Contrairement aux assembleurs, les programmes écrits avec des langages de haut niveau peuvent être utilisés sur plusieurs ordinateurs (mais au prix de modifications plus ou moins importantes), ce qui permet de réduire les coûts de programmation. Construits autour de syntaxes qui rappellent le langage naturel, ils permettent une écriture et une lisibilité plus faciles des programmes. Par exemple, l’instruction "VAR" signifie variable en Pascal, "PRINT" signifie imprimer en Basic.

La plupart des langages de haut niveau ont été écrits à l’origine pour des applications spécifiques : ♦ le Fortran pour automatiser des calculs scientifiques ; ♦ le Basic pour gérer les applications en temps partagé sur un ordinateur central ; ♦ le Pascal pour enseigner la programmation structurée ; ♦ le Cobol pour l'informatique de gestion.

Les langages évolués sont classés en trois grandes familles : ♦ les langages procéduraux : le FORTRAN, le COBOL, le BASIC, l’Ada, le PASCAL et le C ; ♦ les langages orientés-objets: le C++ et le Java ; ♦ et les langages orientés-listes ; le LISP.

Les programmes écrits en langage de haut niveau nécessitent également d'être traduits (transposés) en langage-machine (cf. § 2.3).




Destinés à l'origine aux utilisateurs non-informaticiens (d'où leurs nom de langage "naturel"), les langages de quatrième génération qualifient les langages propres aux bases de données (appelés également langages de requêtes).

Se situant un cran au-dessus des langages évolués, ils se composent d’un jeu d’instructions s’apparentant à des macro-instructions (séquences d’instructions prédéfinies) permettant : ♦ les déclarations de données ("langage définition de données") ; ♦ et les manipulations de ces données (langages de manipulation formels utilisant l'algèbre

relationnel).

Exemple de langage : le langage SQL (Structured Query Language).


On voit qu'après la pléthore de dialectes des années 70, l'invention de langages a stagné quand à la syntaxe. Les langages courants, même récents comme Java, C#, PHP, n'apportent aucun changement aux instructions du traitement.

De 1992 à 2000, les concepteurs paraissent s'être consacrés à implémenter l'orientation objet sur tous les langages existants ...

Aucun nouveau langage d'application, mais apparition de langages Internet comme JavaSript, ASP, PHP, qui tendent à mêler données et fonctions de traitement. La cinquième génération pourrait être celle des langages Internet, fonctionnant sur toute machine et compilés en code intermédiaire (dit virtuel).

La tendance la plus récente est de transformer les document XML en exécutables. Les langages "Markup" inspirés de XML sont la dernière tendance, ils intègrent le code et les données sous une forme extensible, et qui fonctionnent sur le Web.

Le futur en programmation pourrait être dans la combinaison des données et du code. La plate-forme .Net peut le faciliter, mais le langage XML peut aussi être une alternative. Même si le C# s'annonce comme un best-seller, ce sera grâce à la force de l'habitude, et comme successeur du C++ et de Java. La plate-forme de développement .NET de l'éditeur Microsoft, en permettant d'utiliser des langages différents avec les librairies existantes, devrait favoriser l'apparition de nouveau langages, plus intéressant parce que plus proche de la pensée, beaucoup plus que ne le sont les langages actuels.

3. TYPOLOGIE DES LANGAGES

Il existe plusieurs écoles de programmation et donc plusieurs types de langages de haut niveau. A ce jour, les principales catégories de langages sont : ♦ les langages impératifs ; ♦ les langages déclaratifs (ou fonctionnels, ou orientes listes) ; ♦ les langages de requête ;



♦ les langages de scripts ; ♦ les langages descriptifs.

3.1. Les langages impératifs

Les langages impératifs correspondent à un style de programmation dans lequel les instructions qui modifient les données sont exécutées simplement les unes après les autres, avec quelques structure de contrôle permettant de créer des boucles ou des alternatives. Il s'opposent en cela aux langages déclaratifs (cf. § 3.4).La programmation impérative est basée sur l'affectation (on parle souvent d'effet de bord, ce qui correspond à un changement de l'état d'une zone de mémoire). Ainsi, dans ce style de programmation, le système d'information passe d'un état initial à un état final. Ces effets de bords (ces changements d'états) peuvent porter sur des éléments de granulosités très diverses : données élémentaires (alpha numérique, numérique, flottants, ...) ou agrégats (ensembles de sous-données élémentaires ou non).

Les langages impératifs peuvent être classés en deux catégories : ♦ d'une part, les langages procéduraux ; ♦ d'autres part, les langages orientés objets.

La différence essentielle réside dans le fait que l'on intègre (ou non) les comportements à la donnée. Pour certains langages, comme par exemple C++, les deux modes de programmation sont proposés.

3.2. Les langages procéduraux

Les langages procéduraux sont des langages où la procédure (suite d’instructions) constitue l’élément de base du programme. Les premiers langages de programmation ne disposaient pas de la notion de procédure et étaient complètement déstructurés. Ces langages étaient peu adaptés aux problèmes réellement complexe, et ils ont rapidement laissé la place aux langages évolués qui disposaient de la notion de procédure.

La plupart des langages évolués sont des langages procéduraux.

Les langages procéduraux permettent de baser l'écriture du programme sur l'algorithmique, méthode de formalisation du processus de traitement qui permet de transformer une donnée initiale en une donnée finale. On raisonne donc sur le processus de traitement dans sa totalité, et l'on définie donc une succession d'appel de procédures (ou de fonctions). Les données passent alors au second plan.

Une procédure est une portion de programme qui accomplit une tâche spécifique nécessaire au traitement. Certaines de ces procédures sont intrinsèques, elles sont intégrées au langage, il suffit de les appeler en nommant la procédure et son argument, par exemple COS(X) qui calcule le cosinus du nombre contenu dans la variable (X). D'autres procédures sont dites extrinsèques parce qu'elles sont écrites par le programmeur.

Parmi les langages procéduraux les plus connu citons : ♦ le Cobol dans le domaine de la gestion ; ♦ et le C qui est encore utilisé de nos jours pour la réalisation de programmes et de systèmes

d'exploitation.

Ces langages procéduraux peuvent être aussi bien :



♦ compilés (Fortran, Cobol, Algol, Pascal et C) ; ♦ qu'interprétés (Basic et APL).

3.3. Les langages orientés objets

Les langages orientés-objets sont des langages adaptés à un style de programmation où chaque programme est considéré comme un ensemble d’objets distincts, ces objets constituant eux-mêmes des ensembles de structures de données et de traitements intégrées.

Les langages orientés-objets sont des langages non procéduraux dans lesquels les éléments du programme sont considérés comme des objets qui peuvent s'échanger des messages. Programmer "objet" consiste donc à créer des objets et à passer des messages entre ceux-ci.

Dans de tels langages, chaque objet appartient à une classe qui définit les structures de données et les méthodes (traitement) associées à cet objet.

Le premier langage à introduire les notions d’objet et de classe a été SIMULA, développé en 1967 par Dahl, Mayrhaug et Nygaard à Oslo. Aujourd’hui, les langages orientés-objets, comme C++, Java, OBJECTPASCAL, OBJECTIF-C, EIFFEL ou SMALLTALK, sont devenus les outils des développeurs.

3.4. Les langages déclaratifs (ou fonctionnels, ou orientes listes)

La plupart des développeurs n'auront jamais à se soucier de langages autres qu'impératifs au cours de leur carrière, aussi l'intérêt d'étudier les autres types de langages peut leur sembler extrêmement limité. Pourtant, la connaissance d'un langage déclaratif ouvre à d'autres manières (peut-être plus efficaces ou plus appropriées dans le cadre d'un projet donné) de résoudre un problème posé, introduit des concepts et des solutions vraiment indépendantes du langage, facilite la compréhension de la relation entre algorithme et programme, et surtout augmente la palette des choix d'outils à disposition...

Les langages déclaratifs énoncent des connaissances (l'énoncé d'un problème) et fournissent un mécanisme de résolution. Ils sont plutôt destinés aux applications relevant du domaine de l'intelligence artificielle. Ils se différencient des langages impératifs par le fait : ♦ qu'ils ne nécessitent pas la programmation de procédures exactes. Il suffit pour le

programmeur de déclarer la tâche qu’il veut faire exécuter à l’ordinateur ; ♦ et que l'appel et la définition de fonctions sont des objets du langage.

Un langage déclaratif repose sur l'idée que tout (ou presque) est fonction; d'où son autre nom de langage fonctionnel. Cela n'est possible qu'avec des notations non classiques (au sens de Pascal, C, etc…), des structures de données non conventionnelles et des mécanismes dédiés d'interprétation. Il découle tout naturellement de ce dernier point que ces langages ne peuvent être complètement compilés (un résultat de type fonction dépend des paramètres d'appel de la fonction génératrice : son code ne peut être connu qu'à l'exécution) et sont donc généralement interprétés (bien que des techniques de compilation avancées résolvent les problèmes).

Avec des langages déclaratifs, la programmation s'effectue en écrivant des fonctions qui appellent d'autres fonctions (d'où leur nom de langages fonctionnels) ... Le résultat d'une fonction peut être une fonction (qu'on pourra plus tard appeler). Chaque fonction est indépendante du contexte, et le résultat d'une fonction dépend exclusivement de ses arguments.

Pour tirer au mieux parti des fonctions, le langage déclaratif utilise des structures de données adaptées. Si on réduit toute instruction à un appel de fonction, on conçoit qu'on peut réduire toute structure de données à un modèle unique, celui de liste (terme traditionnel qui vient de Lisp), d'où son autre nom de langage orientés listes. On peut aussi réduire (ou assimiler) un appel de fonction



à une liste car si on convient de noter les listes entre parenthèses et de séparer les éléments par des espaces, au lieu de la notation fonctionnelle Plus(x,y) on peut écrire, en utilisant une notation listielle (Plus x y).

La notion de liste est plus fondamentale que celle de fonction puisque tout est liste alors que remplacer (x y z...) par Liste(x,y,z...) ne permet pas de tout inclure comme fonction. C'est pourquoi Lisp ne s'appelle pas Foncp (LISt Processing rather than FONCtion Processing).

Les listes sont alors les seules structures de données et doivent, pour répondre aux exigences des différentes fonctions être dynamiques (de longueur non fixe), hétérogènes (les éléments de la liste ne sont pas forcément de même nature), emboîtables (un élément d'une liste peut contenir une autre liste) etc. Le moyen classique de gestion et d'utilisation des listes est alors la récursivité, qui amène le problème de la lisibilité (là-encore), de l'efficacité, de l'optimisation et de la mise au point.

Les langages déclaratifs peuvent s'apparenter aux langages orientés-objets, à la différence qu’ils manipulent non pas des objets mais des listes, c’est-à-dire des structures de données multi-éléments à organisation linéaire (ils sont appelés pour cela "langages orientés-listes").

Parmi les langages déclaratifs les plus connus, notons LISP, Logo et Prolog.

3.5. Les langages de requêtes

Les langages de requêtes constituent, à l’heure actuelle, les outils privilégiés des bases de données. Ce sont des langages anglophones permettant de manipuler les données de façon plus simple et plus rapide que des traitements spécifiés en langage impératif.

Le principal langage de requête est SQL (Structured Query Language : langage de requêtes structuré). Il se compose de 4 sous ensembles : ♦ les requêtes ou interrogations (Query) ; ♦ les traitements de manipulation des données (DML : Data manipulation language) ; ♦ les traitements de définition des données (DDL : Data definition language) ; ♦ les traitements de contrôle des données (DCL : Data Control Language) ;

3.5.1. LES REQUETES OU INTERROGATIONS

Elles consistent en des traitements permettant de retrouver des données, selon plusieurs combinaisons. Elles commencent par le mot réservé "SELECT" (sélectionner), suivi des données valeurs recherchées et des tables contenant les données. Les requêtes ne changent pas les données. Elles ne servent qu’à retrouver l’information.

Exemple : l’exécution de la requête "SELECT NOM, EMPLOI FROM EMPLOYÉS" créera une liste contenant les noms et emplois de tous les enregistrements de la table "EMPLOYÉS".

3.5.2. LES MANIPULATIONS DE DONNEES

Ces traitements modifient des données sélectionnées par l’intermédiaire de l’un des trois mots réservés : ♦ "INSERT" : ajoute de nouvelles lignes dans une table ; ♦ "UPDATE" : met à jour les valeurs présentes ; ♦ "DELETE" : supprime des lignes.

Exemple : L’exécution de la requête

"DELETE FROM EMPLOYÉS WHERE NOM IN (‘JULES’, ‘CÉSAR’)"



supprimera les enregistrements de la table "EMPLOYÉS" dont le champ nom vaut "JULES" ou "CÉSAR".

3.5.3. LES DEFINITIONS DE DONNEES

Ces traitements sont principalement utilisés pour créer de nouvelles tables ou pour supprimer des tables temporaires.

Exemple : L’exécution de la requête

"DROP TABLE OLDEMPLOYÉS" supprimera la table "OLDEMPLOYÉS".

3.5.4. LE CONTROLE DES DONNEES

Ces ordres permettent de contrôler l’accès aux bases de données avec le mot réservé "GRANT" (octroyer).

3.6. Les langages de scripts

Les langages de scripts sont apparus pour développer plus rapidement, ils sont plus éloignés de la machine ce qui les rend plus aisés à utiliser et plus portables. Ils sont peu structurés en général, aux fonctionnalités limitées, essentiellement utilisé pour automatiser certaines petites tâches fastidieuses.

Ils s'utilisent également dans un environnement contenant des applications, des librairies etc ... qu'ils vont utiliser. On dit qu'ils permettent de coller ou de faire communiquer toutes ses composantes. Ils ne sont en revanche pas très adaptés pour écrire des grosses applications autonomes ou manipulant des données très complexes (bases de données). Les deux types de langages sont complémentaires mais pour l'utilisateur final, il devient de plus en plus facile d'utiliser les langages de scripts pour les tâches courantes (prototypage, interface graphique, script de gestions etc ...).

En général les langages de scripts sont interprétés alors que les langages systèmes sont compilés. L'interprétation permet un développement plus rapide et plus portable. La perte de vitesse due à l'interprétation n'est généralement pas un problème pour les scripts "typiques". A noter que la plupart de ces langages sont maintenant aussi "compilables" (du moins en code Java).

Les principales caractéristiques des langages de scripts: ♦ apprentissage faciles ; ♦ fiables, faciles à installer et généralement gratuits ; ♦ portables, extensibles et suffisamment rapides.

Il existe plusieurs langages de scripts qu'il faut choisir en fonction de ses besoins, comme par exemple : ♦ Perl est parfait pour ce qui est traitement de chaînes de caractères et les CGI ; ♦ Tcl/Tk est très bien pour des petits programmes graphiques ; ♦ Python pour de la programmation objet ; ♦ Javascript pour des pages Web dynamiques ; ♦ et VisualBasic pour des applications Windows.



Les langages de scripts s'améliorent de jour en jour, ils deviennent orientés objets, compilables, graphiques etc ... Les machines devenant aussi de plus en plus rapides, leur principal défaut (la lenteur de l'interprétation) tend à disparaître. Leur aptitude à rassembler d'autres applications les rend aussi de plus en plus indispensables. Ils vont continuer à se développer dans l'avenir et ils risquent bien de supplanter la plupart des langages "systèmes" du moins pour la programmation la plus courante.

3.7. Les langages descriptifs (ou hypertextuels)

Les langages descriptifs sont née des besoins générés dans le domaine de l'édition. Ce domaine a été très tôt informatisé. Dans les années 70, de gros systèmes de "traitement de textes" ont été conçus. Ils ont évolué progressivement pour donner naissance aux premiers programmes de PAO sur ordinateur personnel, c'était au début des années 80. Les organismes de normalisation se sont associés à ce progrès. Les gros constructeurs, propriétaires des systèmes des années 70, ont aussi poussé leurs solutions et leurs langages.

Le besoin de donner de la longévité aux documents stockés électroniquement a mené au développement d'un langage spécialisé standardisé. SGML (Standard Generalized Markup Language) est une norme (en 1986, ISO 8879) de balisage d'applications et de création de documents échangeables. SGML est un métalangage servant à définir d'autres langages de balisage. Les langages de balisage DTD (Document Type Definition) sont des langages descriptifs, par opposition aux langages procéduraux.

SGML a été conçu pour permettre : ♦ la création de documents échangeables et révisables ; ♦ la création de langage conçu pour les systèmes de saisie de textes et de mise en page de

textes ; ♦ la de recherche d'informations et de partage de documents.

Le développement d'Internet a suscité de gros besoins en matière de langages de présentation de l'information. Les principaux langages descriptifs nés de SGML sont HTML, DHTML et XML.

4. LANGAGES ET PROCESSUS DE TRADUCTION

L'utilisation d'un langage de programmation permet d'écrire le programme ainsi écrit s’appelle programme-source (ou code source). Le programme-source est un fichier "texte" (encore appelé "texte source"), manipulable par un opérateur humain mais qui ne peut être directement exécuté par l'ordinateur.

Pour que le programme puisse être directement exécuté par le processeur, il est nécessaire de convertir (traduire) le programme-source en un ensemble d'instructions en langage-machine (assimilable par l’ordinateur) appelé programme-objet (ou code objet).

Ce processus de conversion du code source en code objet est assuré par un programme de traduction capable de convertir le texte source, par application de règles de syntaxe et de sémantique en un programme-objet.



Suivant la nature du langage de programmation employé et du processus de traduction, ce programme s’appelle un compilateur ou un interpréteur.

De la manière dont ils sont traduits, les langages informatiques peuvent grossièrement se classer en deux catégories : ♦ les langages interprétés ; ♦ et les langages compilés.

4.1. Les langages interprétés

Un interpréteur procède instruction par instruction, en la traduisant l'instruction puis en l'exécutant dans le même temps. Les résultats sont donnés à mesure que se déroule le programme. S’il y a erreur, le programme bloque, il faut rectifier pour poursuivre.

Les programmes interprétés sont en général plus lents que les programmes compilés. Parmi les plus connus, notons APL, Basic, Logo, etc.

Remarque :

Un interpréteur ne produit donc pas de programme objet (exécutable), le programme-source est aussi le programme-objet exécutable.

4.2. Les langages compilés

Un programme écrit dans un langage dit "compilé" va être traduit en une seule fois par le compilateur afin de générer un nouveau fichier (le programme objet) qui sera autonome, c'est-à-dire qui n'aura plus besoin d'un programme autre que lui pour s'exécuter (on dit d'ailleurs que ce fichier est exécutable).

Le programme source est créée dans la phase de rédaction qui s'effectue à l'aide d'un éditeur de texte.

4.2.1. PHASE DE COMPILATION

Le texte source ainsi rédigé est soumis au compilateur qui examine chaque ligne du programme source, vérifie la syntaxe et génère un code intermédiaire. Suivant les directives de compilation, le compilateur substitue des symboles, inclut des fichiers sources etc... A l'issu de la phase de compilation, le compilateur produit un rapport (1) sur l’ensemble des erreurs de syntaxe (2) constatées. Il faut les corriger et les "re-compiler" de nouveau pour avoir un programmable correctement exécutable. Si la compilation ne génère aucune erreur, un programme objet est généré et soumis à la 2ème étape de la compilation, l'édition de lien.

4.2.2. PHASE D'EDITION DE LIEN

Dans cette phase, l'éditeur de liens (linker) produit le code exécutable du programme : ♦ dans le cas où le programme objet est découpé en plusieurs fichiers sources, rassemble les

codes intermédiaires et à les lier aux diverses librairies ; ♦ traduit le programme objet en langage machine ; ♦ résout les adressages mémoires.



Parmi les compilateurs les plus connus, on trouve Fortran, Cobol, Algol, Pascal, C, etc.

Remarque :

(1) Le compilateur ne produira le fichier exécutable que si le code source est correct (si le rapport de compilation est vierge).

(2) Les erreurs de logique ne peuvent être décelées que grâce aux tests effectués sur le programme objet.

4.3. Avantages et inconvénients des deux mode de traduction

Un programme écrit dans un langage compilé a comme avantage de ne plus avoir besoin, une fois compilé, de programme annexe pour s'exécuter. De plus, la traduction étant faite une fois pour toute, il est plus rapide à l'exécution.

Toutefois il est moins souple qu'un programme écrit avec un langage interprété car à chaque modification du fichier source il faudra recompiler le programme pour que les modifications prennent effet.

D'autre part, un programme compilé a pour avantage de garantir la sécurité du code source. En effet, un langage interprété, étant directement intelligible (lisible), permet à n'importe qui de connaître les secrets de fabrication d'un programme et donc de copier le code voire de le modifier. Il y a donc risque de non-respect des droits d'auteur. D'autre part, certaines applications sécurisées nécessitent la confidentialité du code pour éviter le piratage (transaction bancaire, paiement en ligne, communications sécurisées, ...).

5. DESCRIPTION DES PRINCIPAUX LANGAGES

5.1. Langages procéduraux

5.1.1. LE LANGAGE FORTRAN Premier langage de programmation de haut niveau, le FORTRAN (acronyme de FORmula TRANslation) a été développé entre 1954 et 1958 par John Backus d’IBM. Il est à l’origine de nombreux concepts avancés, tels que les variables, les expressions, les instructions, les sous-programmes compilés séparément et les entrées / sorties formatées. Langage compilé et procédural, le FORTRAN a été créé pour être appliqué aux domaines scientifiques et techniques. Malgré de nombreuses et récentes améliorations, le FORTRAN est de moins en moins utilisé.

5.1.2. LE LANGAGE COBOL Acronyme de COmmon Business-Oriented Language, le COBOL a été développé entre 1959 et 1961 et officialisé par le département américain de la Défense (dont il a été un temps le langage obligatoire). Le COBOL est un langage procédural classique destiné à la gestion d’entreprise, dans lequel un programme est composé de 4 divisions :



♦ la division Identification, qui fournit le nom du programme et celui de l’auteur, ainsi que toutes les informations annexes que ce dernier estime nécessaires ;

♦ la division Environment, qui indique le modèle d’ordinateur cible, ainsi que les fichiers utilisés en entrée comme en sortie ;

♦ la division Data, qui décrit les données traitées par le programme ; ♦ et enfin la division Procedure, qui contient l’ensemble des sous-programmes définissant les

actions du programme. qui peuvent comporter des sections.

Il est fondé sur les données et défini précisément le matériel et les formats d’entrées et sorties de données. Il introduit la structure de donnée RECORD. Les programmes sont auto-documentés par la syntaxe.

5.1.3. LE LANGAGE BASIC Acronyme de Beginner’s All-purpose Symbolic Instruction Code, le langage BASIC est un langage procédural de haut niveau, développé vers le milieu des années 1960 au Dartmouth College par John Kemeny et Thomas Kurtz.

L’énorme succès de ce langage est dû à deux de ses versions, Tiny BASIC et Microsoft BASIC, grâce auxquelles le BASIC est devenu le langage de référence de la micro-informatique.

Mais il existe également d’autres versions importantes de ce langage : Integer BASIC et Applesoft BASIC (Apple), GW-BASIC (IBM), QuickBASIC ou Visual Basic qui intègre la gestion d’interfaces (Microsoft).

Le langage BASIC a ainsi évolué au fil des années, passant d’une forme interprétée à des versions compilées.

5.1.4. LE LANGAGE PASCAL Mis au point entre 1967 et 1971 par Niklaus Wirth, le langage Pascal est un langage procédural et compilé, dérivé du langage ALGOL. Destiné à traiter des données informatiques, il simplifie la syntaxe d’ALGOL tout en y ajoutant des types et des structures de données supplémentaires, tels que les types énumérés, les fichiers, les enregistrements et les ensembles.

Bien que le Pascal soit un langage résolument procédural qui excelle dans la réalisation d’applications mathématiques. Il existe également une version de Pascal orientée-objet, utilisée aussi dans le développement d’applications. Il est souvent enseigné aux étudiants en raison de sa programmation efficace et très structurée.

5.1.5. LE LANGAGE C Succédant au langage B, le langage C (d’où son nom) a été développé en 1972 par Dennis Ritchie dans les laboratoires Bell de la société AT&T. C'est un langage procédural.

Bien que le langage C s’apparente à un langage assembleur indépendant de la machine plutôt qu’à un langage de haut niveau, il peut cependant être considéré comme un langage de programmation standard, en raison de sa grande popularité, de son association avec le système d’exploitation UNIX et de sa normalisation par l’ANSI (American National Standards Institute).

Excepté quelques fonctions natives, le langage C est doté de fonctions indépendantes de la machine, contenues dans des bibliothèques auxquelles peut accéder tout programme écrit en C.



5.2. Langages orientés-objet

5.2.1. LE LANGAGE C++ Le langage C++, version orientée-objet du langage de programmation C, a été développé par Bjarne Stroustrup dans les laboratoires Bell (AT&T) au début des années 1980, puis adopté par certains constructeurs tels qu’Apple Computer ou Sun Microsystems.

Assimilé d’un côté à une extension du langage C, mais considéré de l’autre comme un langage doté d’une approche objet (il reprend de SIMULA l’essentiel de sa partie objet), le langage C++ s’impose aujourd’hui, grâce à ses fonctions très puissantes, comme le langage de référence de développement de programmes.

5.2.2. LE LANGAGE JAVA

Dérivé du langage C, inspiré du langage C++, mais plus simple que ce dernier, le langage Java, signifiant "café" dans l’argot américain, est un langage procédural classique orienté-objet. Il a été développé par la société Sun Microsystems en 1991. Les premières versions du langage ont été diffusées en 1995.

Son succès a été favorisé par sa grande utilisation sur le Web pour pallier les manques du langage HTML, notamment pour traiter les animations et l’interactivité. De plus, le langage Java est portable, c’est-à-dire qu’il peut être interprété par de nombreuses plates-formes. Ainsi, une applet (petit programme écrit en Java) est une application compilée qui s’exécute sur le poste client où est affichée la page HTML, à la différence d’une servlet qui est une application compilée qui s’exécute sur le serveur Web.

Le langage Java dispose d’une riche bibliothèque de classes, qui permet notamment de gérer les interfaces graphiques et l’accès aux fichiers.

5.2.3. LE LANGAGE C# Crée en 2000, le langage C# (prononcer C sharp) a été conçu par Microsoft pour en faire le langage de prédilection de la plateforme .NET. II peut être vu comme une réponse de Microsoft face au langage Java de Sun, étant donné qu'il est directement Inspiré du C++ et de Java, et possède également une Inspiration de Visual Basic. En particulier, le C# met en oeuvre un garbage collector pour libérer le programmeur de la gestion de la mémoire, Ies variables sont automatiquement Initialisées et les constructions qui peuvent Introduire des erreurs lorsqu'elles sont mal utilisées sont défavorisées. De plus. un programme écrit en C# sera converti d'abord en un langage Intermédiaire. analogue à la machine virtuelle de Java, commun aux différents langages de la plate-forme ,NET. Microsoft a soumis le langage à l'organisation ECMA pour en faire un standard reconnu et a obtenu gain de cause en décembre 2001.

Langage de base de la plateforme ".NET", le langage C# permet de programmer des logiciels utilisables à distance sur Internet notamment. Ce langage est promis à un grand succès. Comme Java, il reprend la syntaxe du langage C avec les mêmes simplifications: garbage collector, absence de pointeur, pas d'héritage multiple, interfaces, multi-tâche...

Le C# se compile en langage intermédiaire , le MSIL (MicroSoft Intermediate Language), et fonctionne avec une bibliothèque multi-langages, le CLR (Common Language Runtime). L'originalité essentielle est que des langages différents peuvent être compilés en MSIL et partager leurs classes. D'autres innovations ont été incluses au langage : ♦ les structs sont ici des objets spéciaux passés par valeur. ♦ Les littéraux sont des objets, avec des méthodes.. ♦ Les attributs sont des objets descriptifs attachés aux éléments du programme et utilisés par le

runtime.



♦ Les propriétés: une méthode définie comme propriété est utilisée comme une variable: prop = 5 est équivalent à prop(5).

♦ Le construct foreach() pour parcourir des tableaux (nouveau seulement par rapport au Java et au C++).

♦ Le delegate qui remplace le pointeur de fonctions du langage C.

Par rapport au Java, outre les différences ci-dessus : ♦ La gestion d'évènements est mieux intégrée. ♦ Il conserve la surcharge des opérateurs du C++ ♦ Accès plus simple au système natif.

5.3. Les langages de requête (SQL)

Acronyme de Structured Query Language, le langage SQL est utilisé dans les systèmes de gestion de bases de données, permettant notamment de définir les structures des données, de spécifier les utilisateurs et leurs droits ou d’interroger les bases de données existantes.

Dérivé du projet de recherche d’IBM qui avait conduit à l’élaboration du langage SEQUEL (Structured English Query Language), le langage SQL est une norme mondialement reconnue et répandue. Il peut être employé pour formuler des questions de manière interactive, mais aussi inséré dans un programme sous forme d’instructions de manipulation de données (cf. § 2.2.3).

5.4. Les langages déclaratifs

5.4.1. LE LANGAGE LISP

Sigle de LISt Processing, LISP est un langage de programmation orienté-liste, développé vers 1960 par John McCarthy au MIT (Massachusetts Institute of Technology), et utilisé principalement pour manipuler des listes de données.

Lisp utilise le principe de réduction de problème,

En rupture complète avec les langages procéduraux de l’époque, LISP est un langage interprété dans lequel chaque expression représente une liste d’appels à des fonctions. Toujours fréquemment utilisé dans les milieux universitaires, LISP a longtemps été considéré comme un standard en intelligence artificielle, même si, depuis quelques années, le langage Prolog commence à revendiquer la même position.

5.4.2. LE LANGAGE PROLOG

Acronyme de PROgramming in LOGic, Prolog est un langage conçu par Alain Colmerauer et Robert Kowalsky dans les années 1970, le premier compilateur ayant été développé en 1972 à l’université d’Aix-Marseille par Philippe Roussel.

Conçu à l’origine pour la programmation logique, ce langage s’est depuis largement répandu dans le domaine de l’intelligence artificielle. Prolog est un langage compilé fonctionnant sur le principe de résolution par des prédicats de premier ordre, relations logiques entre données, plutôt que sur des relations mathématiques.



5.5. Les langages de scripts

5.5.1. LE LANGAGE PHP

Créé en 1994, le langage PHP (Personal Home Pages Hypertext Processor) est un langage de script interprété exécuté du côté serveur et non du côté client (un script écrit en Javascript ou une applet Java s'exécute côté client). Il est devenu en quelques années d'existence, le langage de programmation de sites Web dynamiques le plus populaire.

De même que le serveur Web Apache, la plate-forme Linux et le gestionnaire de base de données MySQL, le langage PHP s'appuie sur un logiciel Open Source, libre et gratuit. Il demeure la solution la plus économique pour développer des applications internet à un coût minimum.

Les scripts PHP, à l'instar de l'ASP (Active Server Pages) de Microsoft, sont incorporés directement avec le balisage HTML, au sein d'une page Web. Associé à MySQL, le langage PHP permet de développer des applications Web puissantes reliées si nécessaire à des bases de données.

Empruntant des concepts à des langages tels que Perl ou C, PHP est un langage capable de fonctionner sur n'importe quelle plate-forme. En effet, chacun des systèmes d'exploitation de Microsoft, Unix, Linux ou encore Mac OS X, peut devenir un support pour des applications Internet écrite en PHP en accueillant un module spécifique s'intégrant au serveur Web en place. Ainsi, la plupart des serveurs Web à l'image de Microsoft IIS (Internet Information Server), Netscape Enterprise Server ou encore Apache, supportent parfaitement la technologie PHP.

En outre, le langage PHP possède de nombreux outils facilitant sa connectivité à des bases de données comme non seulement son SGBDR (Système de Gestion de Bases de Données Relationnelles), MySQL, mais aussi quasiment tous les autres tels que Sybase, Oracle, SQL Server ou DBase.

La version 4.0 (crée en 1999) actuellement utilisée cèdera sa place en 2005 à la version 5, qui le dotera de nouvelles possibilités et le transformera en un langage de programmation complet.

5.5.2. LE LANGAGE PERL

Crée en 1987, le langage Perl est un des langages scripts les plus utilisés. Destiné à remplacer les langages de ligne de commande d’Unix (Sh et Sed ainsi que Awk), il reprend la même (affreuse) syntaxe

Très prisé par les ingénieurs systèmes, il avait la mauvaise réputation d'être illisible avant la versions 5. Perl sert surtout à l'administration de système, et aux scripts CGI. Une de ses grandes forces réside dans les modules qui permettent d'étendre le langage. La programmation objet est aussi possible depuis les versions 5.

5.5.3. LE LANGAGE JAVASCRIPT

Lancé par Netscape pour contrôler les serveurs Web, le langage Javascript (attention à ne pas confondre avec Java) s'est peu à peu imposé pour le développement de pages Web interactives. En effet le navigateur Web de Netscape intègre un interpréteur Javascript. On peut aussi utiliser Javascript en dehors du Web mais il faut alors se procurer un interpréteur.

Exemple en Javascript : "script"

function fibonacci(n)



{

if(n>1) return fibonacci(n-1) + fibonacci(n-2);

if(n==0) return 0;

return 1;

}

for (i=0; i<100; i++){

document.write("Fibonacci number "+i+" is "+fibonacci(i)+"

");

}

"/script"

5.5.4. LE LANGAGE VISUALBASIC

Le langage Visual Basic, langage de référence sur Windows, permet de très facilement écrire des programmes graphiques sous cet environnement. Ses principaux défauts: il n'est pas gratuit et pas portable.

Exemple en Visual Basic : function Fibo(n)

Dim Tempo

If n = 0 Then

Tempo = 1

Else

If n = 1 Then

Tempo = 1

Else

Tempo = Fibo(n - 1) + Fibo(n - 2)

End If

End If

Fibo = Tempo

End Function

5.5.5. LES SHELLS UNIX (SH, CSH, KSH, BASH, ...)

Les plus anciens langages de scripts, le Bourne Shell (sh) a toujours été fournit avec Unix, c'est d'ailleurs une des raisons du succès d'Unix comme plate-forme de développement. Ils sont en général rudimentaires mais très portables. Ils sont encore très utilisés aujourd'hui.

Exemple en sh : #!/bin/sh -f

A=0;B=1

while [ $B -lt 1000 ]

do

echo $B



A=$B

B=`expr $A + $B`

done

5.5.6. LES ASP (ACTIVE SERVER PAGES)

Les ASP (Active Server Pages) sont un standard de l'éditeur Microsoft permettant de développer des applications Web interactives, c'est-à-dire dont le contenu est dynamique.

Une page Web ASP (repérable par l'extension .asp) aura un contenu pouvant être différent selon certains paramètres (des informations stockées dans une base de données, les préférences de l'utilisateur,...) tandis que page Web "classique" (dont l'extension est .htm ou .html) affichera continuellement la même information.

Il s'agit en réalité d'un langage de script puissant (un langage interprété) exécuté du côté du serveur (au même titre que les scripts CGI, PHP, ...) et non du côté client (les scripts écrits en JavaScript ou les applets Java s'exécutent dans le navigateur de la personne connectée à un site).

Les ASP sont intégrables au sein d'une page Web en HTML à l'aide de balises spéciales permettant au serveur Web de savoir que le code compris à l'intérieur de ces balises doit être interprété afin de renvoyer du code HTML au navigateur du client.

Ainsi, les Active Server Pages s'inscrivent dans une architecture 3-tier. Dans une telle architecture, un serveur supportant les Active Server Pages peut servir d'intermédiaire entre le navigateur du client et une base de données en permettant un accès transparent à celle-ci grâce à la technologie ADO (ActiveX Data Object).

La technologie ADO fournit les éléments nécessaires à la connexion au système de gestion de bases de données, à la manipulation des données grâce au langage SQL.

5.6. Les langages descriptifs (ou hypertextuels)

5.6.1. LE LANGAGE HTML

Le célèbre langage HTML, parent direct de SGML, est apparu au début des années 1990. Son propos est la publication d'information, ce qu'en d'autres termes on peut appeler la présentation d'une information contenue dans un contenant structuré. Ce langage connaît un véritable engouement depuis sa création.

Le World Wide Web Consortium (W3C) est l'instigateur de la norme HTML.

Plusieurs versions se sont succédés : ♦ HTML 1.0 (1991 obsolète) ; ♦ HTML 2.0 (septembre 1995 obsolète) ; ♦ HTML 3.X (mai 1996 en voie d'obsolescence) : la plus célèbre est la version 3.2 connue sous

son nom de code "Wilbur".

HTML est un langage hypertextuel très simple et indépendant qui permet de décrire du texte avec des graphiques. Il s'exécute sur toute sorte de plate-forme.

HTML est une DTD (Document Type Definition) normalisée SGML. Il constitue une instance c'est-à-dire un fichier texte, à ceci près que certaines chaînes de caractères sont interprétées comme des balises. Les balises donnent au document sa forme et sa structure (les balises sont des mots



réservés; une balise commence par "<" et ">" et se termine par "<", "/" et ">"). Une instance représente une hiérarchie d'éléments. Chacun d'eux a un nom, des attributs et un contenu. La plupart des éléments sont représentés dans le document par une marque de début, précisant le nom et les attributs, suivie du contenu, lui même suivi d'une marque de fin.

La mise en forme d'un document HTML comporte les éléments nécessaires pour baliser le document, coder la forme des caractères et créer des liens vers d'autres documents. Un document est composé d'une en-tête et d'un corps; l'en-tête comporte des informations générales sur le document; le corps contient le texte du document ainsi que les commandes de formatage.

Le langage HTML comprend : ♦ la définition d'éléments de structuration comme les titres, les listes et les chapitres, mais la

présentation finale est laissée au logiciel de navigation. ♦ bon nombre de possibilités de mise en page (éléments de structure externe au document

comme les en-têtes, les lignes de titre, les différents niveaux de titres) mais aussi les liens hypertextes, les mises en relief, les insertions flexibles de graphiques, de tableaux, de listes et de formulaires ;

♦ la présentation structurée d'éléments de tableau, les tailles et couleurs de polices de caractères, l'agencement du texte autour de l'image, les images cliquables sans communication avec le serveur et l'insertion des applets Java et JavaScript.

HTML (version 4.0) : le standard

En octobre 1997, sous le nom de code "Cougar", une nouvelle norme de standard est faite. Les nouveautés sont nombreuses. Le HTML ne se limite plus aux seuls navigateurs et vise maintenant à s'intégrer aux différents matériels de sortie de l'utilisateur :

L'internationalisation est effective, par exemple les accents du français sont pris en compte ; ♦ La définition des tableaux s'améliore ; ♦ Les formulaires s'enrichissent de fonctionnalités ; ♦ Le tag OBJECT permet d'insérer tout type d'objet et non plus seulement des contrôles ActiveX ; ♦ Les feuilles de style sont adoptées ; ♦ L'impression se fait intelligente (par exemple la possibilité de commander le saut de page) ; ♦ Des événements qui appartenaient aux scripts (par exemple : onmouseover, onload) sont

maintenant reconnus ; ♦ Les frames sont officialisés ; ♦ Les affichages impossibles ont la possibilité d'une alternative.

Après être passé par plusieurs évolution, HTML possède désormais un éventail de dispositifs reflétant les besoins d'une communauté internationale très diverse.

Au cours de l'atelier du W3C sur le "futur de HTML" organisé à San José, Californie, en mai 1998, les discussions ont porté sur la possibilité d'une prochaine génération de HTML. A la fin de l'atelier, on a convenu que la seule façon de progresser était de s'appuyer sur une nouvelle génération de HTML. XML n'était plus très loin.

5.6.2. LE LANGAGE XML XML, eXtensible Markup language, est un langage de balisage extensible", développé par le W3C. Ceci signifie que X Ml n'est pas lImIté, au contraire du HTML. à un balisage prédéfini extrêmement figé, mais que tout un chacun pourra définir ses propres balises. Le XML cherche avant tout, à dissocier tes données de leur mise en forme. Le HTML lui aussi a évolué dans ce sens, en Introduisant depuis quelques années la notion de feuilles de style, mais ceci n'a rien à voir avec la dissociation beaucoup plus structurée établie par le XML



Le langage XML est l'aboutissement du lent processus de maturation conceptuel qui aura conduit du document indissociable de la page sur laquelle il est imprimé au document intelligent (enfin presque) où contenu et présentation sont dissociés, manipulables et extensibles.

En 1998 février, la recommandation XML v1.0 voit le jour : ♦ XML bénéficie de la base installée de HTML, de HTTP et des navigateurs Internet ; ♦ XML est simple et portable ; ♦ XML peut décrire des documents de toute complexité ; ♦ XML est plus qu'un simple langage de balise, c'est une vaste famille ! ("XML family") ; ♦ XML est international

Le langage XML ouvre divers champs d'application : ♦ La messagerie : XML en tant que format standard pour l'échange de données (par exemple :

XML/EDI) ; ♦ Les traitements : déplacement du serveur vers le client (par exemple : Electronic Banking,

Electronic Commerce) ; ♦ Le domaine documentaire : XML permet d'exprimer toute l'intelligence du document dans le

document, les applications documentaires peuvent se développer sans contrainte (par exemple : le format EIDE pour la GED) ;

♦ Les processus collaboratif : les Intranets bénéficieront largement des documents XML. Avec HTML, la même information était préparée pour tout le monde, maintenant le choix de la restitution peut revenir au client. L'auteur décide du contenu, le lecteur de la présentation ;

♦ La publication : présentation variable de l'information ; publication dans différents formats avec XSL ; publication automatisée (par exemple à partir des bases de données) ;

♦ La recherche : Recherche intelligente d'information ; ♦ L'intégration de système : Echanges automatisés, EAI, etc.


Les outils d'aide au developpement

LES OUTILS D'AIDE AU DEVELOPPEMENT L'idée des langages de programmation est aussi vieille que celle du calculateur digital.

Il suffit de programmer un ordinateur directement en code binaire pour comprendre immédiatement pourquoi.

1. LES ATELIERS DE GENIE LOGICIEL (AGL)

L’expression "atelier de génie logiciel" (AGL) n’est pas toujours très claire. La confusion vient des différentes offres commerciales qui nomment ainsi tout outil d’aide au développement pour peu qu’une passerelle logicielle permette de le mettre en relation avec son environnement.

Un AGL est un ensemble d’outils logiciels intégrés autour d’un référentiel, c’est-à-dire autour d’un système de mémorisation et de contrôle de cohérence des éléments composant le logiciel pendant son cycle de vie.

L’AGL doit offrir une possibilité de navigation rapide parmi des vues très différentes du logiciel : spécifications, langages, méthodes de conception.

Il existe deux grandes familles d'AGL :

♦ Les AGL de conception (Upper Case) qui apporte des outils d'aide à l'élaboration des modèles (de données et de traitement, à la rédaction de la documentation, production de dictionnaire de données, …

♦ Les AGL de réalisation (Lower Case) qui permettent la génération "automatique" de certains composants du code source.

L’utilisation d’un AGL permet de respecter des principes de développement utiles à la portabilité.

2. LE DEVELOPPEMENT PAR ASSEMBLAGE DE COMPOSANTS

Le développement par assemblage de composants (frameworks) sont des progiciels constitués par assemblage de modules spécialisés développés séparément et réutilisables.

Ce mode de conception s’annonce comme une alternative aux PGI (progiciels de gestion intégrés). Les grands progiciels devront faire face à une nouvelle forme de concurrence : celle des frameworks métiers. Ces produits, encore peu nombreux, souvent liés à des outils de développement, seront dynamisés avec l’arrivée des solutions EJB (Enterprise Java Beans).

Les PGI, parce qu’ils sont déjà bien implantés et dotés de processus paramétrés, sont encore dominants sur le marché, mais ils ont l’inconvénient d’offrir une souplesse très limitée d’adaptation à l’organisation de l’entreprise. Or, les décideurs souhaitent un maximum de souplesse pour pouvoir rendre leurs entreprises plus rapidement productives et concurrentielles.

Les frameworks répondent mieux à ces objectifs, en donnant aux entreprises la capacité de réaliser les processus qui les intéressent en respectant leur organisation, sans qu’il soit nécessaire de développer les composants de base (objets métier). Aux entreprises qui s’appuient encore sur des développements spécifiques, elles offrent le compromis espéré entre coût et souplesse.


Les outils d'aide au developpement

3. LES OUTILS DE DEVELOPPEMENT VISUELS

Tous les outils de développement visuels, depuis les interfaces graphiques jusqu'aux générateurs de programmes, permettent des accroissements de la productivité dans un rapport qui peut aller de 1 à 5.

Ces outils avaient été initialement dédaignés par les programmeurs adeptes de C ou de C++.

Mais grâce aux accroissements de productivité et à une plus grande facilité de création ou de modification, les programmeurs "à la souris" gagnent du terrain, si l'on en juge par la percée de Visual Basic, y compris dans les développements d'applications professionnelles.

Il ne serait donc pas étonnant que l'outillage de base du programmeur du futur s'appuie sur des outils visuels, des techniques objets et des bibliothèques de composants.


La réingénierie (retro-conception)

LA REINGENIERIE (RETRO-CONCEPTION) Avec le temps, la maîtrise d'une application, d'un système d'information peut être menacée. Des maintenances successives ont pu altérer sa conception initiale et distorsionner la visibilité sur ses fonctionnalités réelles.

La réingénierie (reengineering en anglais), consiste en une remise à plat de ce qui a été conçu à l'origine, qu'il s'agisse : ♦ soit de recouvrer une meilleure connaissance du système d'information existant ; ♦ soit d'atteindre de meilleurs niveaux de performances globales ; ♦ soit de transformer une architecture applicative (par exemple initialement tournée vers la

production en un dispositif orienté vers le client).

A partir d'un existant applicatif, la réingénierie consiste en des travaux de "rétro-conception" qui permettre de se "ré-approprier" les différents niveaux d'abstraction de l'application.

Dans le secteur informatique, plusieurs branches sont concernées par cette discipline (les deux premières étant très liées) : ♦ la réingénierie des systèmes d'information ; ♦ la réingénierie des processus ; ♦ la réingénierie logicielle.

Toute opération de réingénierie s'appuie sur un référentiel documentaire qui matérialise la visibilité d'une application. Or la documentation a toujours été le maillon faible parmi les livrables d'un projet informatique. Les résultats d'une étude de l'organisme de normalisation américain IEEE en témoignent : 95 % des applications spécifiques ont une documentation incomplète ou obsolète.

Aussi la plus grande part des travaux de réingénierie englobe des travaux de rétro-documentation, c'est-à-dire de reconstitution du référentiel documentaire d'une application, préalable à tout autre travaux.

1. DOMAINE DE COUVERTURE D'UN REFERENTIEL DOCUMENTAIRE

Un degré important de carence du référentiel documentaire fait encourir à l'entreprise un risque quant à la maintenabilité, la pérennisation et l'évolutivité de son système informatique. Les travaux de réingénierie doivent aboutir à la re-constitution d'un référentiel documentaire en engageant des travaux de "rétro-documentation".

1.1. Domaine de couverture d'un référentiel documentaire

Relativement à une application d'une certaine dimension, et dans l'idéal, un référentiel documentaire regroupe un ensemble de dossiers descriptifs des différents niveaux d'abstraction du domaine automatisé.

1.1.1. LE NIVEAU CONCEPTUEL : MODELISATION DES PROCESSUS METIERS

Ce niveau est formalisé par le dossier des spécifications générales qui contient : ♦ la formalisation des règles de gestion propres à chaque processus (le "QUOI") ;



♦ et la description des aspects organisationnels ("QUI", "FAIT", "OU"), découpage et enchaînement entre les tâches automatisées et celles restées manuelles.

1.1.2. LE NIVEAU FONCTIONNEL : DESCRIPTION DE L'AUTOMATISATION (LE "COMMENT")

Ce niveau est formalisé par le dossier des spécifications détaillées qui comprend les modélisations : ♦ des données, accompagnée d'un dictionnaire détaillant leurs caractéristiques ♦ et des traitements.

ainsi que la constitution d'un guide d'utilisation.

1.1.3. LE NIVEAU TECHNIQUE

La documentation (dossiers d'analyse, de programmation, d'exploitation) décrit l'architecture applicative, l'ensemble des composants mis en jeu : programmes, fichiers et bases de données ainsi que les divers aspects relevant de l'architecture technique.

1.2. Risques encourus avec une documentation périmée, perdue ou inexistante

Un degré important de carence du référentiel documentaire fait encourir à l'entreprise un risque quant à la pérennité de son système informatique.

L'activité naturelle d'une entreprise (ou administration) de taille importante entraîne des évolutions conceptuelles et/ou techniques des systèmes d'information qui peuvent se traduire par de simples retouches adaptatives, comme par de véritables re-conceptions, voire des restructurations. Ces évolutions peuvent impacter différents niveaux (conceptuel, organisationnel, ou physique) et concerner les données et/ou les programmes applicatifs.

Pour un système d'information de cette dimension, le référentiel documentaire constitue une base essentielle et le seul moyen (d'appréhension) qui soit de nature : ♦ à conserver une maîtrise de l’automatisation existante (dans ses différents niveaux

d'abstraction) ; ♦ à faciliter les tâches de maintenance en permettant la mesure précise des impacts (techniques

et financiers) de toutes évolutions, à quelques niveaux que ce soit (conceptuel, fonctionnel et technique) ;

♦ à préparer les travaux de migration vers d’autres technologies.

Le degré de carence du référentiel documentaire entraîne, en proportion, une sur-consommation des ressources humaines et financières. En présence d'une documentation défectueuse, toute évolution de niveau réglementaire, toute correction de dysfonctionnement, toute opération de migration technique, deviennent complexes, et donc coûteuses.

Dans de telles situations, maintenir des applications, intervenir sur des logiciels pour les faire évoluer ou corriger des dysfonctionnements deviennent des opérations délicates, surtout lorsque le code est écrit dans un langage obsolète, et que l'entreprise a perdu les compétences adéquates.

Les informaticiens chargés de la maintenance en sont réduits alors à utiliser le code source comme principal moyen de documentation. De ce fait, ils consacrent la majorité de leur temps, non à apporter aux programmes les aménagements nécessaires, mais à rechercher l'information et à tenter de la comprendre.

Et dans les situations les plus inextricables, le risque majeur peut conduire à la perte de la maîtrise totale de l'application et contraindre à sa réécriture.



On le constate donc, un référentiel documentaire est de nature à donner une vision claire de son système d’information à toute organisation faisant l'objet d'une informatisation de son activité.

Cela sous-entend qu'une véritable gestion de projet soit mise en place selon des outils méthodologiques clairement définis.

2. DEMARCHE ET LES OUTILS (METHODOLOGIQUE ET LOGICIELS)

Compte tenu des risques encourus et lorsque la dimension du système informatique l'exige, une véritable gestion de projet accompagnée d'outils méthodologiques doivent être mise en œuvre afin d'engager les travaux de "rétro-documentation".

2.1. Structure de projet et démarche à mettre en place

Compte tenu de l'ampleur des travaux de re-documentation, il est suggéré la constitution de structure proche de celles nécessaire à la conduite d'un projet, à savoir : ♦ d'une instance de suivi stratégique de type "comité de pilotage", composée de décideurs

représentant : • la maîtrise d'ouvrage (MOA) ; • la maîtrise d'œuvre (MOE) ; • et les utilisateurs ;

♦ et d'une instance de suivi opérationnel de type "groupe de projet", composé : • d'un chef de projet MOA ; • d'un chef de projet MOE ; • d'assistants MOA (concepteur) et MOE (analystes, programmeur) ; • et de représentants (significatifs) des utilisateurs (gestionnaire de processus).

2.1.1. LE COMITE DE PILOTAGE

Ce comité de pilotage initiera la mise en place d'une étude de faisabilité (étude préalable). S'il le juge opportun, le comité de pilotage pourra confier cette étude à un prestataire externe, en collaboration avec le groupe de projet.

A l'issue de cette étude préalable, le groupe de projet définira le périmètre des travaux de retro-documentation accompagné d'un calendrier prévisionnel. Le recours à un prestataire externe pourra également être envisagé par le comité de pilotage si l'entreprise ne peut dégager les ressources humaines nécessaires à la conduite des travaux de retro-documentation.

2.1.2. LE GROUPE DE PROJET

Le groupe de projet conduira l'étude préalable, puis les travaux de retro-documentation. Il rendra compte au Comité de pilotage (selon un calendrier à définir) : ♦ de l'état d'avancement des études ; ♦ des difficultés rencontrées ; ♦ de tout dérapage sur le calendrier initial.



2.2. Démarche à suivre

La constitution d'un référentiel documentaire s'effectuera à partir de travaux de réingénierie (rétro-conception) qui permettront la ré-appropriation des différents niveaux d'abstraction du système informatique de l'entreprise.

Lorsque la dimension de l'application (ou du système d'information) l'exige, ces travaux devront inclure à la fois la réingénierie des processus opérationnels (processus métiers). En effet, le degré de complexité (règles de gestion, interactions en processus, dimension organisationnelle forte), ne peut faire abstraction d'une analyse en profondeur des processus opérationnels de l'entreprise.

Mais, la réingénierie s'appliquera également aux applications. A partir de l'étude du code source des programmes, on reconstituera un algorithme de traitement qui permettra de dégager les aspects fonctionnels de ces traitements.

Une double démarche mise en œuvre (et en parallèle) : ♦ une approche "processus" :

une démarche par le haut ("top-down"), la réingénierie des processus, partant des modélisations des processus métier accompagnée d'une modélisation des données pour aboutir aux fonctionnalités des traitements.

♦ une approche "applicative" : concomitamment à la démarche par le haut, une démarche par le bas, basée sur la réingénierie des programmes, partant du code source et des structures physiques des données pour dégager les fonctionnalités applicatives des traitements.

Au niveau de chaque processus, ces deux démarches se recouperont et reconstitueront le niveau fonctionnel (applicatif), en utilisant des "allers et retours" successifs entre le niveau conceptuel et le niveau technique.

Les "points de rencontre" valideront le niveau fonctionnel. Ces travaux seront également l'occasion pour diagnostiquer des dysfonctionnements applicatifs ou une conception non satisfaisante.

Le nouveau référentiel documentaire pourra, autant que de besoin, intégrer des éléments de la documentation existante. Ces éléments ne s'exonéreront pas d'une analyse critique systématique afin d'en assurer de leur validité.

Les travaux de rétro-documentation mettront en évidence des règles de gestion et d'organisation, selon différents niveaux (macro ou microscopiques). Chaque règle recensée fera l'objet d'une formalisation (écrite) rigoureuse et validée par le groupe de projet et notamment les représentants des utilisateurs.

Ces documents enrichiront au fur et à mesure le référentiel documentaire ainsi re-constituée.

2.3. Outils méthodologiques (méthodes, AGL, logiciel) nécessaires

La formalisation du niveau conceptuel pourra être facilitée par l'utilisation d'outils de modélisation, issus de méthode d'analyse (Merise) ou de langage graphique de modélisation (UML).

La méthode d'analyse Merise est plus particulièrement préconisée pour la modélisation des traitements batch, le langage graphique de modélisation UML plus particulièrement pour les traitements par nature interactifs.



Les travaux de rétro-documentation des programmes effectués de façon manuelle représentent une lourde charge. Celle-ci peut être allégée par l'utilisation d'outils logiciels, laquelle est préconisée pour la formalisation du niveau technique.

En quelques années, les solutions de rétro-documentation automatisée ont fleuri, proposées par des éditeurs et des prestataires comme Acfo, Cast, Cyrano, Metaware, NGSet, Sapiens ou Sodifrance. Ces logiciels analysent automatiquement et rapidement l'ensemble du code de l'application.

D'autres logiciels comme Microsoft Visio assure la rétro-documentation automatique de bases de données et la modélisation de logiciels avec rétro-documentation automatique de code Visual Basic, C++ et C# .

Ces outils logiciels contiennent plusieurs composants tels que des analyseurs syntaxiques, des extracteurs d'arborescences ou encore des moteurs de réécriture. Ils identifient la structure du code, puis procède à des opérations prédéfinies, adaptées aux spécificités du code et aux améliorations souhaitées , avec autant de passages que nécessaire.

L'opération de ré-ingénierie est alors plus rapide et plus fiable que si elle avait été menée manuellement. Les éléments inutiles sont éliminés, les programme sources "liftés", les éléments restants sont normalisés et harmonisés.

Le code est ainsi stabilisé, rationalisé, simplifié. Les traitements deviennent plus faciles à analyser afin d'en extraire les fonctionnalités applicatives et la logique de fonctionnement. Certains logiciels (par exemple "SC Rules") recherchent et identifient les règles de gestion à partir d’une analyse exhaustive du code applicatif existant. Les instructions (ou ensemble d'instruction) se révélant être des règles de gestion peuvent être identifiées.

Les règles ainsi sélectionnées seront validées par le groupe de projet et intégrées dans le référentiel documentaire.

3. CONTENU DETAILLE DES TRAVAUX DE "RETRO-DOCUMENTATION"

3.1. Contenu détaillé des travaux de l'étude préalable

Les objectifs assignés à cette étude conduiront : ♦ à la préconisation d'une démarche de retro-documentation ; ♦ à la définition des outils méthodologiques (méthodes, AGL) nécessaires à cette démarche ; ♦ à l'élaboration du périmètre des travaux de retro-documentation ; ♦ à l'établissement d'un calendrier prévisionnel de déroulement de ces travaux.

3.1.1. ELABORATION DU PERIMETRE DES TRAVAUX DE RETRO-DOCUMENTATION

Après une étude d'opportunité sur le niveau de documentation, le groupe de projet proposera, pour chaque application "critique", soit sa retro-documentation, soit sa ré-écriture complète.

Les processus correspondant à ces applications seront identifiés. Les utilisateurs représentatifs de ces processus seront associés à ces travaux.



Les progiciels et logiciels, censés posséder une documentation établie par leur éditeur, seront naturellement exclus du périmètre de ces travaux.

3.1.2. FIXATION D'UN CALENDRIER PREVISIONNEL DE DEROULEMENT DES TRAVAUX

L'étude préalable permettra l'estimation des coûts de ces travaux en terme de ressources humaines et financières. L'utilisation d'outil de suivi de projet est préconisée tel que par exemple les diagrammes de GANTT et les logiciels associés ("MS-Project" notamment).

3.2. Contenu détaillé des travaux de rétro-documentation

3.2.1. RAPPEL DE LA DEFINITION D'UN PROCESSUS METIER

Le processus peut se définir comme un regroupement cohérent d’activités, disposant de ressources, alimenté par des entrées, qui sont transformées en sorties en y apportant une valeur ajoutée.

En d'autres termes, un processus est un enchaînement cohérent de tâches (automatisées ou non) concourant à la production de résultats.

3.2.2. RE-APPROPRIATION DES PROCESSUS METIERS

Au sein de chaque processus (totalement ou partiellement) automatisé, cette étape conduira à sa décomposition en séquences élémentaires pour identifier chaque activité du processus.

La modélisation des séquences de travail mettra en évidence des règles de gestion propre à chaque activité.

3.2.3. UNE VISION PLUS DETAILLEE DES FONCTIONNALITES DES APPLICATIONS

La rétro-documentation de l’application doit permettre de renforcer sa connaissance fonctionnelle.

La réingénierie d'une application peut être divisée en 2 grandes étapes.

Tout d'abord l'acquisition de la sémantique précise des données (système de fichiers classiques ou bases de données) et des modules applicatifs. Elle s'appuie sur l'analyse des données et des programmes qui les manipulent.

Ensuite la représentation correcte de cette sémantique : ♦ s'agissant de données, on construira le modèle logique des données :

• schéma physique pour une base de données ; • description des enregistrements pour les fichiers classiques.

♦ - pour les programmes, à partir du code source, on reconstitue l'algorithme de traitement.

Bien évidemment, les résultats de ces analyses, tant au niveau conceptuel que technique, feront systématiquement l'objet d'une formalisation écrite.



4. CONCLUSION

On vient de le constater, les travaux de retro-documentation ont un coût non négligeable.

Aussi est-il primordial que le référentiel documentaire ainsi reconstitué : ♦ fasse l'objet de mises jour régulières ; ♦ soit accessible facilement par chacune des parties prenantes, à des titres divers, selon leur

niveau de compétence (habilitation) ; ♦ et soit administré selon une organisation clairement définie (désignation d'un administrateur,

de niveaux d'habilitation, …).


Institut de la Gestion Publique

et du Développement Economique 20, allée Georges Pompidou

94306 Vincennes cedex SERVEUR PEDAGOGIQUE INTRANET

http://alize.alize/crp/tic

2004

Documents

FASCICULE INFORMATIQUE GENERALE - resoo.org · 5. La maintenance ... 4. Langages et processus de traduction ... d’organisation du travail (la taylorisation)