Apprentissage du troisième partiel

Lors de ce troisième partiel, l’accent a été mis sur la correction du développement logiciel, que ce soit à travers la révision du code, la vérification et validation ou encore les tests en programmation orientée objet.

La constante dans ces trois différentes méthodes est qu’elles se déroulent plutôt a posteriori du développement lui-même et permet de vérifier que celui-ci est bon, tant sur l’aspect technique que sur celui de la réponse aux attentes du client.

Ces trois sujets me paraissent intimement liés en cela qu’ils sont complémentaires et indispensables au bon développement du logiciel. En particulier, la phase de révision du code est à mon sens un catalyseur des deux suivantes. Un code bien révisé comportera moins d’erreurs et sera plus clair, comme nous l’avons vu dans le blogpost dédié à ce sujet. En cela, il rendra la phase de test et de vérification plus facile. En effet,en suivant cette logique, ces tests devraient être plus facile à construire puisque le code sera plus lisible, mais devraient également comporté un taux d’échec significativement plus faible puisque constitué de moins de bugs. Cela représente une optimisation assez indéniable des ressources humaines, financières et de temps pour les phases suivantes.

Enfin, les tests en environnement OO et la vérification/validation sont intimement liés puisque la vérification et la validation font partie intégrante de ces test. Ils permettent à mon sens de rendre un produit de plus grandes qualités, et permet de limiter la phase d’accompagnement et de correction des bugs postérieures à livraison du projet. Ils permettent également de s’assurer de la satisfaction du client en fournissant un produit fiable et pertinent, instaurant ainsi une relation de confiance avec ce-dernier.

Reflection plus générale

Ce cours d’introduction au management du développement de logiciels m’aura beaucoup appris et me sera certainement très utile dans ma carrière que j’envisage à la frontière du management et de la programmation. Cela m’a également permis de mettre en perspective certaines des connaissances acquises lors de mon premier stage au cours duquel j’ai participé à la PMO d’un projet SAP. Cela m’a aidé à clarifier certains points que je n’avais vu qu’appréhender en surface.

Je n’ai malheureusement pas eu le temps de terminer les deux derniers blogposts car j’ai été fortement pris par mes contraintes hors du TEC. Toutefois, cela m’apprend également que malgré mes progrès ma gestion du temps et des différentes échéances est encore loin d’être parfaite et qu’il me faudra continuer de progresser sur cet aspect pour ma carrière futur.

La phase de test en développement orienté-objet

La phase de test en développement OO (orienté-objet ou object oriented) consiste à tester dans son intégralité le projet de développement logiciel.

Tester le logiciel dans son intégralité implique d’aller au delà du code en lui-même. Les différents aspects à tester sont les suivants:

source: http://www.ambysoft.com/essays/floot.html

Les différents types de test

On distingue principalement trois types de tests:

• Tests unitaires

Les tests unitaires sont des tests dit “en boîte blanche” (c’est à dire qu’ils se concentrent sur le code source lui-même, cela correspond à la phase de vérification détaillée dans le blogpost “Validation et Vérification”). Ceux-ci vont tester le bon fonctionnement du logiciel partie par partie. Le principe est de vérifier que chaque partie du logiciel fonctionne correctement indépendamment des autres

• Tests d’intégration

Les tests d’intégration interviennent l’immense majorité du temps à la suite des tests unitaires. On peut les considérer comme la deuxième phase des tests en “boîte blanche”. En revanche, cette fois-ci, l’accent est mis sur l’articulation des différentes parties du code entre elles. Dans les tests unitaires, on a vérifié que les différentes du code fonctionnaient de manière indépendante, on vérifie maintenant qu’elles “s’ intègrent” correctement, qu’elles fonc

• Tests de validation

Un test de validation est un test dit “en boîte noire”. Il est généralement effectué par le client qui valide partiellement ou complètement le comportement du système. Pour de plus amples informations sur les tests de validation, se référer au blogpost “Validation & Verification”. En synthèse, le but des tests de validation est de déterminé si le logiciel développé répond effectivement aux attentes pré-établies en début de projet.

Conclusion

Ces trois phases de tests sont donc très importantes dans le développement de logiciel et s’enchaînent assez naturellement. D’abord, on vérifie que chaque sous-partie du code fonctionne en tant que telle, pour ensuite vérifier qu’elle s’intègre bien dans le projet à une échelle plus globale. Enfin, une fois que ces tests sont passés avec succès et que le logiciel fonctionne sur l’aspect technique, la phase de validation vérifie qu’il répond effectivement aux attentes définies en début de projet.

Vérification et validation : différences et complémentarité

Souvent confondus, la vérification et la validation de logiciel sont pourtant deux processus bien distincts et non-moins complémentaires primordiaux au développement de logiciels.

Une définition simplifiée de ces deux procédés serait la suivante:

• La vérification tente de répondre à la question suivante: sommes-nous en train de construire le produire de la bonne manière ?
• La validation tente quant à elle de répondre à celle-ci: Sommes-nous en train de construire le bon produit ?

Ces deux questions peuvent sembler très similaires à première vue mais sont en réalité aussi complémentaires que disparates. La vérification est avant tout un procédé technique, cherchant à établir si le logiciel développé va tout simplement fonctionner. Le code est-il construit de manière optimale afin de répondre aux attentes du client ?

La validation, elle, se focalise justement sur les attentes du client. Celles-ci ont-elles été bien comprises ? Le logiciel établi va-t-il effectivement permettre de les satisfaire ?

C’est en cela que ces deux procédés sont également très complémentaires. L’un cherche à vérifier que les besoins du client sont compris, tandis que l’autre tend à s’assurer que le logiciel y répondra correctement.

Articulation des deux procédés

source: https://www.mathworks.com/help/slcoverage/verification-and-validation.html

Comme illustré sur le schéma ci-dessous, ces deux procédés sont à la fois distincts et entrelacés. La vérification peut prendre plusieurs formes (vérification du code objet, vérification du code source, vérification du modèle). C’est une phase plutôt technique qui met l’accent sur le code en lui-même. A l’inverse, la validation relève plus du management de la relation client. Celle-ci intervient à une échelle plus macro, avec une vision plus globale de l’ensemble du projet. Elle se concentre beaucoup moins sur comment le code est exécuté mais plutôt sur à quel fin celui-ci est écrit.

C’est en cela que ces deux méthodes sont particulièrement complémentaires. Tandis que la première assure que le code fonctionne correctement, le second certifie que ce code, correct techniquement, exécute précisément ce qui est attendu de lui.

Risques de la validation et la vérification

En dépit de leur complémentarité et de leur importance, la vérification et la validation doivent être manipulées avec soin, en particulier dans leur articulation. Ce sont des procédés à la fois très différents et entrelacés, qui doivent donc être menées de façon paradoxalement indépendante et articulée. Les compétences requises pour les mener à bien étant largement différentes, leurs acteurs le sont aussi. La bonne communication entre ces-derniers est donc indispensable. En effet, aucun de ces deux process n’a de sens sans l’autre. Un code qui fonctionne correctement mais qui ne répond pas aux attentes du client n’a pas plus de valeur qu’un code qui répond aux attentes du client mais ne fonctionne pas. Différents par nature, la validation et la vérification doivent donc pourtant impérativement être menées de concert afin d’assurer le succès du projet.

Qu’est-ce que la révision de code ?

La révision de code consiste en “un examen systématique du code source d’un logiciel”. Présenté en tant que tel, la révision de code peut apparaître comme un processus assez naturel à réaliser. Toutefois, c’est dans sa formalisation qu’elle prend tout son sens. Le mot clé de cette définition est “systématique”. Il ne s’agit pas de réviser le code seulement à l’apparition d’un bug ou quelconque problème – ce qui paraît somme toute assez évident- mais plutôt d’effectuer cet examen de manière récurrente et automatique.

La révision de code permet ainsi notamment d’anticiper des bugs, avant même que ceux-ci ne se manifestent, mais également de corriger du code qui serait difficile à interpréter voire incompréhensible. En somme, la révision de code est un mécanisme d’anticipation, permettant d’être dans la proaction plutôt que la réaction face à d’éventuels problèmes dans le code source.

Comment réaliser une revue de code ?

Avant de se préoccuper de son execution en tant que telle il est important d’identifier les acteurs pertinents qui se chargeront de la relecture du code. L’auteur du code n’est certainement pas la personne la plus appropriée pour ce travail en ceci qu’elle ne sera pas à même d’apporter un regard nouveau et extérieur sur son travail. Cela comporterait le risque que cette personne s’enferme dans sa propre logique et se retrouve aveuglé face à certaine problématiques, nécessitant une approche différente. Ainsi, la relecture de code nécessite l’intervention d’un nouvel acteur, que l’on pourrait qualifier de “relecteur” du code (tandis que le premier en serait l’auteur).

Il n’existe pas de méthode universelle pour la relecture de code mais certaines sont néanmoins particulièrement répandues et certains principes restent inamovibles. Tout d’abord, il est généralement préférable d’attendre que le code soit intégralement rédigé avant de procéder à la relecture. En effet, toute modification postérieure par l’auteur du code imposerait une nouvelle relecture, ce qui n’est évidemment pas optimal en terme de gestion du temps et des ressources. Les méthodes les plus répandues sont les suivantes:

• Les pull ou merge requests : Un développeur envoie ses changements et une autre personne valide et intègre le moment venu.
• « Analyse par-dessus l’épaule » : L’auteur commente son code et le relecteur donne des conseils ou pose des questions en direct.
• La revue de code par mail : Il est possible de faire une simple liste de diffusion et de s’envoyer des patchs par mail. La relecture se fait alors directement par retours de mails.

Pour de plus amples informations, le site ci-dessous est particulièrement clair et détaillé:

https://zestedesavoir.com/articles/2889/la-revue-de-code-cest-important/

Bénéfices de la révision de code

Comme mentionné en introduction, la révision de code comporte des avantages multidimensionnelles.

Sur l’aspect purement technique d’abord, il permet de limiter et surtout d’anticiper d’éventuels bugs dans le code source. Le double regard permet de combiner deux approches différentes, et idéalement complémentaires, et donc de déceler plus d’inconsistances. Cela permet également d’obtenir un code plus clair, car pour permettre la communication entre les deux protagonistes il est nécessaires que le code soit lisible et intelligible par ces deux-mêmes personnes.

Sur l’aspect humain, la relecture de code permet également aux deux protagonistes de progresser considérablement en étant confronté à des méthodes et des manières de penser différentes. Les deux doivent faire un effort de compréhension de l’autre et de son travail et ainsi sortir de sa zone de confort. Comme évoqué dans le paragraphe ci-dessous, cela les force également à soigner leur communication et l’écriture du code afin de faciliter le dialogue. Et pour exprimer clairement ses idées aux autres, il est nécessaire que celles-ci soient claires pour soi-même.

Reflexion générale:

Je poursuis mon apprentissage de la gestion de projet de développement, et en parallèle je continue d’apprendre sur mes méthodes de travail dans un contexte beaucoup plus libre qu’à l’accoutumée. Ayant un emploi du temps plus chargé qu’au premier partiel en raison de mes obligations pour mon école en France, je dois apprendre à mieux m’organiser dans mon travail pour ne pas prendre trop de retard. Mon groupe et moi avons notamment pris du retard dans notre projet de groupe, que nous avons réussi à compenser en fin de période. En ce qui concerne les rendus individuels je pense avoir trouvé un bon rythme de travail, en essayant de prendre de l’avance dans les périodes plus calmes, quitte à ne pas toucher à mon blog pendant une semaine ou deux lorsque mon flux de travail se fait plus intense.

De manière plus concrète, voici les principaux enseignements dont je tire de ce second semestre:

UML

L’UML est l’acronyme anglais pour langage de modélisation unifié. C’est un langage initialement destiné au développement logiciel mais qui s’est popularisé à d’autres domaines. Il permet à la fois de s’affranchir des contraintes du texte et de la barrière de la langue en créant un langage purement visuel constitué de diagrammes compréhensibles par tous. L’UML est utilisé en phase d’analyse d’un projet, et intervient donc dans la phase de cadrage du projet. Le but est de donner une ligne directive aux différentes parties prenantes du projet, permettant ce faisant de garder une certaine cohérence dans des projets parfois extrêmement longs et complexes, et ainsi de gagner en efficacité et en efficience.

Classes to tables

Ce sujet est plus compliqué pour moi étant donné qu’il est plus technique qu’à l’accoutumée et que mes connaissances techniques en programmation sont assez limitées.

Toutefois j’en retiens que convertir des classes en une base de données permet à la fois non seulement de clarifier le programme, mais également de le sécuriser en créant des relations entre ses différentes classes. L’établissement de relations entre les différents éléments via les classes primaires et étrangères permettent d’assurer la cohérence des informations et de limiter les erreurs d’origine humaine.

Classes to code

De même, sur ce sujet, la limite de mes connaissances et de ma compréhension m’obligent à rester sur des considérations assez générales. J’en ai tout de même retenu que la programmation est née avec l’assembleur qui est un langage s’adressant directement à la machine. Ce sont ensuite développés les langages fonctionnelles et orientés objet, qui communiquent à la machine via un compilateur qui joue le rôle d’interprète. La POO (programmation orientée objet) s’est considérablement popularisée si bien qu’aujourd’hui, l’écrasante majorité des langages de programmation répandus sont orientés objet. Ce type de programmation jouit en particulier de sa facilité à être réutiliser, son mode de communication entre objets via des interfaces et son caractère modulaire.

Les différents langages de programmation

Comme pour le poste précédent, je précise qu’ayant des compétences limitées en programmation, je n’aurai pas la prétention ici de rentrer dans des considérations techniques qui dépassent mon champ de connaissance et de compréhension. Je vais ici m’atteler à présenter une vue générale des différents types de langages de programmation, de leurs avantages et de leurs inconvénients, et dans quel contexte les utiliser.

L’origine des langages de programmation est l’assembleur. Inventé en 1945 par John von Neumann, c’est le plus proche du langage machine puisqu’il s’adresse directement au processeur. Toutefois, il en est par la même très compliqué à comprendre et manipuler. De plus, il existe autant de langage assembleur qu’il existe de famille de processeurs, ce qui rend sa maîtrise d’autant plus complexe.

Les langages modernes utilisent un compilateur comme une sorte d’interprète entre le codeur et la machine, ce qui facilite grandement la communication entre les deux. Deux principaux types de langages se sont développés au cours du temps: les langages fonctionnels et les langages orientés objet.

Programmation fonctionnelle vs Programmation orientée objet

Le tableau ci-dessous résume les différences entre programmation fonctionnelle et orientée-objet.

Source : https://waytolearnx.com/2018/12/difference-entre-programmation-orientee-objet-et-programmation-fonctionnelle.html

	Fonctionnelle	Objet
Définition	La programmation fonctionnelle met l’accent sur l’évaluation des fonctions.	Programmation orientée objet basée sur un concept d’objets.
Les données	La programmation fonctionnelle utilise des données non modifiable.	Orienté objet utilise les données modifiable.
Programmation parallèle	Programmation parallèle prise en charge par la programmation fonctionnelle.	La programmation orientée objet ne prend pas en charge la programmation parallèle.
Exécution	En programmation fonctionnelle, les instructions peuvent être exécutées dans n’importe quel ordre.	Dans la POO, les instructions doivent être exécutées dans un ordre particulier.
Itération	En programmation fonctionnelle, la récursivité est utilisée pour les données itératives.	Dans le POO, les boucles sont utilisées pour les données itératives.
Élément	Les éléments de base de la programmation fonctionnelle sont les variables et les fonctions.	Les éléments de base de la programmation orientée objet sont les objets et les méthodes.
Utilisation	La programmation fonctionnelle est utilisée uniquement lorsqu’il y a peu de choses avec plus d’opérations.	La programmation orientée objet est utilisée lorsqu’il y a beaucoup de choses avec peu d’opérations.

Emergence du langage orienté objet

Aujourd’hui, les langages les plus populaires sont presque exclusivement des langages de programmation orientés objet. Comment expliquer ce phénomène ?

Tout d’abord, la POO (programmation orientée objet) est plus facilement réutilisable. Les types d’objets créés peuvent servir de base pour la création de nouveaux. Il n’est pas nécéssaire de tout reprendre de zéro à chaque fois, et il est donc plus facile de réaliser des travaux se basant sur d’autres travaux déjà existants.

Elle est également plus compréhensible car chaque objet contient ses propriétés et ses méthodes de manière intrinsèque. Il est donc facile de savoir ce que manipule une fonction et à quoi correspondent les différentes variables.

Enfin, la POO génère un code dit modulaire. En d’autres termes, les objets communiquent entre eux via des interfaces définies et bien connues. Cela permet de développer aisément des modules interagissant avec des interfaces déjà connues et utilisées.

Introduction et définitions

Comment convertir le design de classes en un tableau constituant une base de données ? Afin de répondre à cette question il s’agit tout d’abord de clarifier ce qu’on entend par design de classes et base de données.

En programmation, une classe est une entité contenant un certain nombre de champs et de méthodes, appelés membres de cette classe. Définir une classe c’est donc déterminer les caractéristiques qui serviront à représenter différents types d’objets. Pour prendre un exemple concret dans la vie de tous les jours, on pourrait définir la classe des fruits, dont les composants seraient la couleur, le goût, la taille,… Un fruit particulier est alors ce qu’on appelle un objet ou une instance de classe. En d’autres termes, la classe est une combinaison de caractéristiques qui, lorsque des valeurs leurs sont associées, se matérialisent en un objet. C’est une sorte de template.

Exemple d’un mapping de classe

Une table de base de données, est un ensemble de valeurs réparties selon un modèle composé de colonnes (que l’on peut identifier par un nom) et de lignes. Le nombre de colonnes est fixé tandis que le nombre de lignes est laissé libre, et varie au gré de la taille de la base de données. Un élément est donc une ligne dans laquelle on fixe des valeurs associées à chaque caractéristique mise en colonne.

Exemple d’une table de base de données :

Convertir des classes en une base de données

Transformer des classes en une base de données nécessite de suivre plusieurs étapes bien précises:

Il s’agit d’abord de réaliser ce qu’on appelle un mapping de classes, comme illustré sur la première image de cet article. Concrètement, cette étape sert à donner plus de lisibilité aux différentes classes, et d’avoir une vision d’ensemble des différents paramètres qui la composent. Ces classes sont composées de clés primaires, qui sont des identificateurs uniques. Par exemple, le numéro d’étudiant d’un élève du TEC peut-être considéré comme une clé primaire de la classe “étudiant”. Elles sont également composées de clés dîtes “étrangères” et qui servent à conserver la cohérence de la base de données en établissant des liens entre différents composants. Prenons un exemple: si un élève emprunte un livre à la bibliothèque en donnant son numéro d’étudiant, mais la bibliothécaire commet une erreur lors de la saisie du numéro étudiant. Une clé étrangère permet par exemple de faire le lien avec le nom de l’étudiant associé à ce numéro, et permet donc à la bibliothécaire de se rendre compte de sa bévue.

Il est ensuite possible de créer des relations entre les différentes classes.

Limites de mes connaissances sur le sujet

Pour être honnête, étant étudiant en business et non pas en codage, mes connaissances et ma compréhension s’en trouvent quelques peu limitées sur ce sujet.

Toutefois, de ce que je peux en comprendre, convertir des classes en base de données permet non seulement de gagner en clarté dans l’établissement du code, mais également de sécuriser les informations que l’on entre. En faisant des associations entre différents composants, il est plus facile de déceler une potentielle erreur humaine ou une incohérence dans les informations qui sont entrées (qui reste possible voire probable lorsque l’on traite d’importants volumes de données).

Définition

UML est l’acronyme anglais pour “Unified Modeling Language”, que l’on traduit généralement par “Langage de modélisation unifié”. Le terme “unifié” est ici central et justifié par le fait que l’UML est un langage fondamentalement visuel et donc compréhensible par tous. L’aspect visuel permet également de rendre ce langage facilement compréhensible, en utilisant principalement des diagrammes.

Il est destiné à l’architecture, la conception et la mise en œuvre de systèmes logiciels complexes par leur structure aussi bien que leur comportement, mais peut aller plus loin en décrivant également tous les flux de processus dans l’industrie autour du logiciel développé. Il a été popularisé par des entreprises comme IBM, Microsoft ou encore Oracle à la fin des années 90.

Il est important de noter ici que l’UML ne s’applique maintenant plus qu’au domaine de la programmation, mais est utilisé largement à tous les échelons de l’entreprise (gestion de stock,…)

Exemple of a UML diagram:

Comment et pourquoi utiliser l’UML ?

L’UML est utilisé en amont du développement logiciel. Le but est de modéliser les besoins du développement futur de manière concise et claire. En cela, on pourrait comparer l’UML à une notice pour monter un meuble : il est beaucoup plus simple et agréable de construire un meuble à partir d’une notice faîte de schémas et d’illustrations plutôt que d’une interminable série d’instructions écrites.

L’UML est basée sur une approche objet, en opposition à la décomposition fonctionnelle. Cette approche s’articule autour de 4 principes fondamentaux. Elle est :

• itérative : elle évolue avec le projet. Il est parfois nécessaire d’effectuer des retours en arrière et de revenir sur les plans initiaux pour les adapter aux nouvelles contraintes.
• guidée par les besoins clients et utilisateurs : le besoin client doit servir de fil rouge tout au long du projet. Plus spécifiquement, lors de la phase d’analyse, qui est celle lors de laquelle l’UML intervient, il est primordial de se concentrer sur l’affinage et la validation des besoins des futurs utilisateurs.
• centrée sur l’architecture du logiciel
• une description des actions et informations dans une seule entité : les différents diagrammes existants dans l’UML apportent différentes visions du logiciel à developper. Néanmoins, le diagramme de classe est particulièrement pertinent pour le développement objet. Il permet d’analyser les actions et informations conjointement et non séparément.

Exemple d’un diagramme de classes:

Atouts de l’UML

Selon moi, l’UML est extrêmement performant pour deux raisons. La première et la plus évidente est qu’il permet de cadrer un projet de développement logiciel de manière visuelle et donc facilement interprétable par tous. L’importance du cadrage d’un projet peut aisément être sous-estimée mais lorsque de multiples acteurs travaillent sur un même projet avec différentes phases interdépendantes il est primordial d’avoir une ligne directive. L’UML est au développement logiciel ce que la carte est à l’explorateur, sans elle il peut errer et se détourner de son objectif initial sans même sans rendre compte.

Le second point fort de l’UML est de créer un langage universel. A l’heure d’une mondialisation toujours plus poussée, les projets impliquent de plus en plus d’acteurs de pays différents et donc a fortiori de langues maternelles différentes. Si l’anglais est maintenant largement répandu et maîtrisé (plus ou moins bien) à l’échelle mondiale, certaines confusions ou difficultés à comprendre des nuances peuvent persister et ajouter des difficultés superflues au projet. En créant un langage standardisé et imagé, la communication entre les différents acteurs est grandement facilitée, puisqu’il s’agit là d’une sorte de seconde langue maternelle pour n’importe quel individu de n’importe quel pays.

Réflection d’ordre général

Avant de rentrer plus en détail sur le contenu du cours j’aimerais revenir sur sa structure. N’ayant quasiment aucune connaissance en programmation informatique, j’avais quelques appréhensions avant d’aborder ce cours. 2 mois plus tard, je suis ravi de constater que le cours est construit de manière à pouvoir être compris par des étudiants de tout niveau en programmation informatique. Malgré certains termes techniques qui m’échappent parfois, je suis rassuré de ne pas être complètement noyé sous les nouvelles notions abordées.

Par ailleurs, la manière d’enseigner ce cours est à mon sens aussi déstabilisante au début qu’agréable, formatrice et responsabilisante. En effet, on nous laisse énormément de liberté, ce qui nous oblige à nous imposer une certaine rigueur pour ne pas perdre le fil du cours, mais qui à la fois nous laisse beaucoup de flexibilité pour organiser notre travail. Cela nous permet de nous adapter au flux d’activités, scolaires et extra-scolaires, qui s’écoule à différentes vitesses pour chacun d’entre nous. En parallèle, malgré le peu de cours magistraux que nous recevons, le professeur est toujours disponible pour répondre à nos questions et nous aiguiller afin que nous ne soyons pas lâcher dans la nature.

Ceci étant dit, concentrons nous sur les différentes choses que j’ai apprises au cours de ces premiers cours. 4 principaux thèmes ont été abordés : Project Life cycle, Unified Software Process, Use Case, Modeling languages & tools et enfin Design Patterns

Software Development Life Cycle

Un life cycle est primordial pour l’édition de tout logiciel. Il définit en quelques sortes la structure managériale du projet. Car si le développement technique est évidemment d’une importance capitale pour la réussite d’un projet, la manière d’articuler ces développements l’est tout autant. Le Life Cycle donne ainsi les grandes phases du projet (par exemple l’analyse, le design, le développement, le testing) ainsi que leurs acteurs.

Il existe de multiples types de Life Cycle mais tous ont pour objectif de structurer le projet. Le waterfall model, dans lequel les étapes se succèdent séquentiellement permet par exemple de donner beaucoup de lisibilité au projet mais ce dernier y perd également en flexibilité. Dans un projet de grande ampleur, constitué de nombreux acteurs et au cours duquel certaines étapes peuvent être amenées à se chevaucher ou à être reconduites, le modèle agile offre plus de flexibilité. Il n’existe pas de modèle par excellence, et le choix de ce dernier doit se faire en fonction des spécificités de chaque projet.

Unified Software Process

L’Unified Software Process a été développé face à la complexité grandissante des développements de logiciel. Afin de les mettre en oeuvre, il était nécessaire de les structurer de manière claire et cohérente. Il détermine les grandes phases d’un projet et permet de ce fait de donner une feuille de route aux acteurs, parfois incroyablement nombreux, d’un projet.

Un USP se doit d’être use-case driven (se base sur l’interaction utilisateur-système), architectural (permet de donner une structure) et itératif (en évolution constante avec le projet et ses avancements).

Use Case

Un Use Case est le liant entre le système et son environnement. Son environnement est constitué d’acteurs non nécessairement humains: il peut s’agir d’un système externe. Il fournit une liste d’instructions à cet acteur afin de réaliser un objectif donné sur le système. On pourrait le comparer à une recette de cuisine où l’objectif serait le plat à préparer et les instructions seraient les différentes instructions.

De plus en plus, on a recours à des Use Case Diagram (voir ci dessous), qui permettent de donner un aspect plus visuel et moins rébarbatif au Use Case.

Modeling languages & tools

Un langage de modélisation est utilisé pour éditer des logiciels. Il existe deux grands types de langage de modélisation à savoir les langages graphiques et textuels. Comme leurs noms l’indique, le premier a vocation à fournir une représentation visuelle du logiciel tandis que le second le fait de manière textuelle, donc plus détaillée mais parfois plus difficile à décrypter.

Ces dernières années ont vu l’avènement des langages graphiques mais cela ne doit toutefois pas masquer les atouts du textuel. Finalement ces deux modèles sont complémentaires, le graphique permettant de faire des représentations simples, concises et faciles d’interprétation, tandis que le textuel permet de donner les informations trop complexes à détailler graphiquement (elles en seraient illisibles).

Design Patterns

Un design pattern est une solution pré-établie à un problème fréquemment rencontré dans le domaine de la programmation. Un pattern permet ainsi d’économiser du temps et de gagner en fiabilité en proposant des solutions connues et déjà testées. Elles peuvent et doivent toutefois être adaptées aux spécificités de chaque situation. Il en existe trois grands types qui sont complémentaires :

• Les creational patterns se concentrent sur la création d’objets et d’instances de classe.
• Les structural patterns permettent de créer une structure cohérente à partir des différents objets créés
• Les behavioral patterns définissent la manière dont ces différents objets communiquent au sein de la structure.

Qu’est-ce qu’un design pattern ?

Lors de l’élaboration d’un logiciel, il est inévitable de rencontrer des difficultés de conception. Certaines de ces difficultés sont redondantes ou récurrentes, à quelques spécificités près. Afin d’éviter de résoudre le problème en repartant de zéro à chaque fois qu’il se présente, on élabore un “design pattern”. Celui-ci est donc en substance une solution pré-établie à un problème fréquent dans le domaine de l’édition de logiciel. Ce pattern peut être adapté pour faire face à la singularité de chaque situation, mais sa structure globale reste la même. C’est une solution standardisée et reconnue fonctionnelle. Ce faisant, le design pattern permet de réaliser des gains de temps, d’énergie et d’argent au sein d’un projet.

Les différents types de patterns.

Les patterns peuvent prendre des formes diverses et variées, mais il est néanmoins possible de les catégoriser en 3 groupes majeurs:

• Les “creational patterns” sont relatifs aux instances de classe ou la création d’objet. Ils peuvent par conséquent être sous-catégorisés en patterns de création de classe ou d’objet. Les “creational patterns” les plus reconnus sont les suivants : Factory Method, Abstract Factory, Builder, Singleton, Object Pool, and Prototype.
• Les “structural patterns” permettent quant à eux de créer des relations entre les différentes entités (classes ou objets) créées. Comme leur nom l’indique, ils permettent de créer une structure à partir des éléments déjà créés. Les plus reconnus sont : Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Private Class Data, and Proxy.
• Les “behavioral patterns” se concentrent sur le comportement des objets ainsi que leurs responsabilités. Ils permettent de déterminer comment ces objets vont communiquer entre eux, souvent via des flux complexes et difficiles à suivre lors de l’exécution du logiciel. Les plus reconnus sont :Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Strategy, Template method, Visitor

Les différents patterns cités en exemple ci dessus sont appelés le gang des 23 “Four Design Patterns”. Si de nombreux patterns existent, ces 23 sont considérés comme la base de tous les autres.

Refléxion sur les design patterns

Les design patterns sont à mon sens primordial dans l’élaboration d’un logiciel car ils permettent de gagner en temps mais aussi en sécurité, étant donné que ce sont des solutions connues et reconnues comme fonctionnelles. Elles permettent de faire de l’élaboration de logiciel un travail collaboratif, réutilisant les solutions déjà établies pour ne pas avoir à tout reconstruire de zéro à chaque fois qu’un problème se présente. Par ailleurs, les trois types de design patterns existant sont extrêmement complémentaires puisqu’ils permettent de créer des objets et des classes, de les organiser en une structure cohérente et de déterminer comment les éléments de cette structure communiqueront entre eux. Toutefois, le risque que j’identifierais serait de considérer le design pattern comme une solution toute faîte, en oubliant les spécificités de chaque situation. Si certains problèmes peuvent présenter de fortes similitudes, chacun n’en demeure pas moins unique et propre à son contexte, et doit donc être traité en conséquence. Les design patterns apparaissent donc comme un outil puissant mais à magner avec précaution.