Reflection partial 1

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.