CSC 4102 – Introduction au génie logiciel pour applications orientées objet

• de spécifier, concevoir et programmer entièrement et de manière systématique un logiciel de petite taille, mais réaliste, dont le cahier des charges est fourni, en utilisant la notation UML et le langage de programmation JAVA,
• d'appliquer des patrons (motifs) de conception et de programmation (idiomes) donnés dans le but d'améliorer la qualité du logiciel,

• de rédiger des tests de validation et des tests unitaires (les tests d'intégration ne sont ni étudiés ni utilisés),
• de programmer et d'exécuter (de manière automatique) les tests,
• d'utiliser des logiciels d'analyse statique de la qualité du code,

• de partager les développements, c'est-à-dire de mettre à disposition dans un gestionnaire de versions les artefacts produits à la fin de chaque séance.

• d'identifier des outils représentatifs des principales activités du processus de développement logiciel,
• d'utiliser des outils pour les activités suivantes : gestion de versions (p.ex. Git), construction de logiciel (p.ex. Maven), spécification et conception avec la notation UML (p.ex. Umlet), programmation en JAVA (p.ex. Eclipse, Javadoc), écriture et exécution de tests (p.ex. JUnit, GitLab CI), et analyse de la qualité du code (p.ex. Checkstyle, FindBugs).

• d'utiliser les commandes et les outils suivants : ls, cd, mkdir, cp, mv, rm, ps, top, kill, Eclipse (ou un environnement de développement équivalent),
• de définir les fonctionnalités d'un gestionnaire de versions (Git) pour gérer les artefacts produits pendant le développement d'un projet informatique : récupération ou rapatriement des mises à jour d'un dépôt, ajout d'un répertoire et d'un fichier, supprimer une entrée de l'arborescence, envoyer des entrées nouvelles ou modifiées vers un dépôt distant.

• de nommer et donner une définition des principaux concepts et des principales activités du développement informatique : processus de développement, cycle de vie d'un logiciel, cahier des charges, exigences, spécification, conception, programmation, tests, et livraison,
• d'effectuer le développement d'un petit logiciel constitué de quelques classes en étant guidé et de manière non systématique.

• de définir et reconnaître les éléments de modélisation de base d'un diagramme de classes UML qu'ils n'ont jamais vu, et plus particulièrement, les concepts et les notations suivants: classe, attribut, attribut dérivé, opération, association, multiplicité, classe d'association, agrégation, et généralisation spécialisation (héritage),
• de lire, comprendre et discuter autour d'un diagramme de classes UML pour comprendre comment est structuré (statiquement) un logiciel de petite taille (une dizaine de classes).

• de définir, reconnaître, utiliser ainsi que critiquer ou défendre l'utilisation des éléments de base d'un programme JAVA qu'ils n'ont jamais vu, plus particulièrement les notions et notations suivantes : syntaxe de base (if switch, for, while, do, while), types (short, int, long, float, double, boolean, byte), conversion de type (cast), attribut (définition, déclaration, final, static), classe (abstraction, encapsulation, class, constructeur, this., this()), objet / instance (référence, new), ramasse-miettes, tableau ([], new), méthode (prototype, définition, paramètre, argument, void, main, surcharge [en anglais overloading], héritage (classe de base, classe dérivée, extends, protected), paquetage (package, chemin de recherche), visibilité (public, private, protected, package friendly),
• de définir et reconnaître les notions et notations suivantes : héritage (méthode polymorphique, super., super(), redéfinition [en anglais overriding], upcast, downcast, liaison dynamique / tardive), classe abstraite (abstract, méthode abstraite), interface (interface, implements), égalité (de références, d'objets, equals),
• de lire, comprendre et discuter à propos d'un logiciel existant de petite taille composé d'une dizaine de classes, comprenant quelques dizaines de lignes chacune.

• nommer le patron de conception MVC avec ses composantes dans les cas d'utilisation qu'ils ont rencontrés : interface graphique et application Web.

Lorsque l'on étudie l'informatique pour devenir ingénieur, on peut se poser la question « pourquoi une ingénierie du logiciel ? » Voici une argumentation donnée par David L. Parnas, ACM SIGSOFT (Special Interest Group on SOFTware engineering) Outstanding Research Award, 1998, extraite de [ParnasSoftEng2010] :

• The branches of engineering (such as civil, electrical, and mechanical), are often referred to as disciplines for good reason. Associated with each specialty is a set of rules that specify: (i) checks that must be made; (ii) properties that must be measured, calculated, or specified; (iii) documentation that must be provided; (iv) design review procedures; (v) tests that must be carried out on the product; and (vi) product inspection and maintenance procedures.
• [Everyday] experiences reminded [us] that the activity we (euphemistically) call software engineering does not come close to deserving a place among the traditional engineering disciplines.
• We are caught in a catch-22 situation (En français, « situation sans issue ») :
  • Until customers demand evidence that the designers were qualified and disciplined, they will continue to get sloppy software.
  • As long as there is no better software, we will buy sloppy software.
  • As long as we buy sloppy software, developers will continue to use undisciplined development methods.
  • As long as we fail to demand that developers use disciplined methods, we run the risk —nay, certainty— that we will continue to encounter software full of bugs.

L'auteur identifie l'une des causes de cette situation : « Much of the fault lies with our teaching. Computer science students are not taught to work in disciplined ways. »

Lorsque l'on programme un logiciel, on peut être amené à se poser la question suivante : « pourquoi spécifier ? » Voici une argumentation extraite d'une conférence de Leslie Lamport, ACM A.M. Turing Award, 2013 [LamportTuringLecture2015,LamportConference2015] :

• Some misconceptions:
  • We can't specify mathematically [or at least semi-formally] what the user wants.
  • If we can't specify correctness, specification is useless.
• Some relevant claims:
  • Not knowing what a program should do means we have to think even harder, which means that a spec is even more important.
  • A specification of what the code does should say everything that anyone needs to know to use the code.
  • If you don't start with a specification, every piece of the code you write is a patch [or at least some pieces].

L'un des objectifs du module CSC4102 est de vous permettre d'appliquer une méthode systématique de conception du cahier des charges à la livraison, en passant par la spécification et la préparation des tests avant la programmation et l'exécution des tests.

Le mouvement d'externalisation de l'activité d'analyse dans des SSII rend-il pour autant le besoin en analyste métier faible ? Voici une argumentation extraite du livre [Clave2016] :

• Le système d'information gère les informations de l'entreprise. Dans une économie de la connaissance, l'information issue des activités opérationnelles, tactiques, stratégiques de l'entreprise est un capital immatériel qui conditionne sa bonne santé.
• Toute satisfaction d'un besoin [est] construite à partir de la représentation, de la formalisation de ce besoin. Plus cette formalisation [est] riche, plus la solution est à la fois riche et adaptée.
• On a souvent tendance à remplacer l'énoncé d'un problème par l'énoncé d'une solution. Une analyse poussée élargit l'éventail des solutions possibles.

L'un des objectifs du module CSC4102 est de permettre d'appliquer une méthode systématique d'analyse du cahier des charges distincte des activités suivantes (conception, etc.), et ce de façon complémentaire à la préparation de tests de validation.

Pour discuter de cette question, nous utilisons les résultats d'une enquête de la pratique de UML dans l'industrie du logiciel [M. Petre2013] :

• [The author identified four main] patterns of use:
  • No UML (35/50): The notation doesn’t really matter. Another in-house formalism that addresses the "whole" system —i.e. software, hardware;
  • Retrofit (1/50): don’t really use UML, but retrofit UML in order to satisfy management or comply with customer requirements;
  • Automated code generation (3/50): UML is not used in design, but is used to capture the design when it stabilizes, in order to generate code automatically (typically in the context of product lines);
  • Selective (11/50): UML is used in design in a personal, selective, and informal way, for as long as it is considered useful, after which it is discarded.
• [About the] "not by me, but by someone else" effect, there [is] a tendency for informants in large organizations who did not themselves use UML, or who used it selectively, to assume that colleagues in other roles were likely to use it more [...] Many informants observed explicitly that colleagues who might be expected to use UML did not.
• [Last but not least,] UML is effective in software engineering education, because of what it captures, and where it directs attention, rather than as a prescription for design actions.

Cette étude publiée dans une conférence en vue du domaine du génie logiciel liste un certain nombre de faiblesses de la notation UML : complexité, manque de sémantique formelle, difficulté à maîtriser la cohérence entre les différentes vues. Notons cependant que la question de l'utilisation d'une notation n'est globalement pas remise en cause, UML étant un des standards disponibles.

Dans le module CSC4102, nous utilisons UML pour décrire les parties du système les plus importantes, et pour apprendre la conception orientée objet ainsi que pour introduire les patrons de conception.

Pour discuter de cette question, nous utilisons le billet de Martin Fowler intitulé « Is Design Dead ? » [FowlerIsDesignDead] :

• eXtreme Programming (XP) challenges many of the common assumptions about software development. [...] To its detractors this is a return to "code and fix" development [...] To its fans it is often seen as a rejection of design techniques (such as the UML), principles and patterns.
  • The primary value of a diagram is communication. Effective communication means selecting important things and neglecting the less important. This selectivity is the key to using the UML well.
  • A common use of diagrams is to explore a design before you start coding it.
  • The last aspect of using UML is for documentation in a handover situation, such as when one group hands over to another. Again the UML is useful here, providing the diagrams are selective to help communication. Remember that the code is the repository of detailed information, the diagrams act to summarize and highlight important issues.
• L'auteur continue avec les conseils suivants, que nous suivrons dans le module CSC4102 :
  • You need to keep to a minimal simple set of notation, and you have to guard against letting any technical issues creeping into the model.
  • So is Design Dead? Not by any means, but the nature of design has changed. XP design looks for [among other skills] knowing how to communicate the design to the people who need to understand it, using code, diagrams and above all: conversation.

Lorsque l'on démarre un projet, par exemple dans une petite structure, on peut se poser la question de passer du temps à discuter de la qualité du logiciel développé. Voici une argumentation extraite d'une publication analysant par enquête le développement logiciel dans les startups [C. Giardion et al.2016] :

• The highest priority is to speed up the development as much as possible by adopting a flexible and effective evolutionary approach. [...] This allows startups to have a functioning but faulty product, that can be quickly introduced to the market.
• However, each line of code, written without following structures and processes, contributes to growing the accumulated technical debt.
• Technical debt concept [FowlerTechDebt2003,CunninghamTechDebt2003]:
  • The idea is that developers sometimes accept compromises in a system in one aspect (e.g. modularity) to meet an urgent demand in some other aspects (e.g. a deadline), and that such compromises incur a "debt" on which "interest" has to be paid and which the "principal" should be repaid at some point for the long-term health of the project. [The literature] identified five dimensions of technical debt: code, design and architecture, environment, knowledge distribution and documentation, and testing.
  • Startups, which survive to subsequent phases will likely increase their user-base, product size, and number of developers. This will require the company to eventually pay the accumulated technical debt, and confront the fact that an initial growth hinders productivity.

L'un des objectifs du module CSC4102 est de permettre d'apprécier la qualité d'un logiciel et d'identifier les possibles dettes techniques qui s'accumulent.

Pour discuter de cette question, nous utilisons la section 42 du livre « The Pragmatic Programmer: From journeyman to main » de Andrew Hunt et David Thomas [HuntThomasPragmaticProgrammer2000] :

• We were once at a client where all the developers were using the same IDE. Their system administrator gave each developer a set of instructions on installing add-on packages to the IDE. These instructions filled many pages —pages full of click here, scroll there, drag this, double-click that, and do it again [...]
• People just aren't as repeatable as computers are. A shell script or batch file will execute the same instructions in the same order, time after time. It can be put under source control so you can examine changes to the procedure over time as well.
• IDEs have their advantages, but with IDEs alone it can be hard to achieve the level of automation that we are looking for. We want to check out, build, test, and ship with a single command.
• Let the computer do the repetitions, the mundane —it will do a better job of it than we would. We've got more important and more difficult things to do.

Dans le module CSC4102, nous utilisons Maven pour construire le logiciel à partir des classes JAVA, pour exécuter automatiquement les tests (en intégration continue avec GitLab CI), voire pour créer le site Web du logiciel.

La modélisation UML permet de construire des diagrammes de cas d'utilisation, des diagrammes de classes, des diagrammes de machine à états, et des diagrammes d'interactions. On peut alors se poser la question de la disparition de l'activité de programmation. Voici l'argumentation « There Will Be Code » extraite des premières pages du livre « Clean Code » de Robert C. Martin [MartinCleanCode2009] :

• One may argue that a book about code is somehow behind the times —that code is no longer the issue; [...] that soon, programmers simply won't be needed because business people will generate programs from specifications.
• We will never be rid of code because "specifying" requirements in such details that a machine can execute them is programming. Such "specification" is code.
• I expect that the level of abstraction of our language will continue to increase. I also expect that the number of domain-specific languages (Un langage dédié est un langage de programmation contenant des constructions pour un domaine d'application donné : par exemple le langage de balisage HTML, le langage d'interrogation de bases de données relationnelles SQL, ou encore les langages MATLAB, GNU Octave et R pour le calcul numérique ou statistique.) will continue to grow. This will be a good thing. But it will not eliminate code.

Dans le module CSC4102, nous n'étudierons pas et n'utiliserons pas de générateur de code à partir des diagrammes UML. Plus particulièrement, nous ne voulons pas que la fonctionnalité « génération de code » d'un outil comme Papyrus soit utilisée pour générer le code de l'application. Ce choix est motivé par la nécessité de comprendre les alignements de concepts entre la modélisation avec la notation UML et le code JAVA écrit.

Nous revenons sur la nécessité d'un outillage adéquat avec une autre catégorie d'outils : « pour l'analyse statique de code ». Pour discuter de cette question, nous utilisons une enquête (appelée une revue de code) effectuée par la société Google sur le code qu'elle produit : « The Google FindBugs Fixit » [AyewahPugh2009].

• In May 2009, Google conducted a company wide FindBugs "fixit". Hundreds of engineers reviewed thousands of FindBugs warnings.
  • Static analysis tools [such as FindBugs] scan software looking for issues that might cause defective behavior.
  • Most interesting software quality problems were eventually found and fixed without FindBugs, but FindBugs could have found these problems early, when they are cheap to remediate.
  • These observations [are attributed] to the success of Google’s testing and monitoring practices.
  • Engineers viewed FindBugs warnings as worth fixing.
  • Over 77% of the reviews identified the warnings as real defects and recommended fixing the underlying problems.

Dans le module CSC4102, nous utilisons SpotBugs (auparavant FindBugs) ainsi que Checkstyle.

Est-il besoin de continuer à « apprendre » un langage de programmation comme JAVA après en avoir étudié les bases ? Nous répondons à cette question en introduisant le concept de patron d'implémentation aussi appelé « idiome », concept étudié dans le module. Pour ce faire, nous utilisons la présentation intuitive qu'en donne G.L. Steele, ACM Grace Murray Hopper Award en 1988, dans la préface du livre « Effective JAVA » de J. Bloch [Bloch 2008].

• If you ever studied a second language yourself and then tried to use it outside the classroom, you know that there are three things you must main:
  1. How the language is structured (grammar),
  2. How to manage things you want to talk about (vocabulary),
  3. The customary and effective ways to say everyday things (usage).
• It is much the same with a programming language:
  1. You need to understand the core language [e.g. JAVA = object-orientation];
  2. You need to know the vocabulary [e.g. the standard library for collections];
  3. You need to be familiar with the customary and effective ways to structure your code [i.e. idioms].

Dans le module CSC4102, nous étudions les idiomes JAVA concernant les méthodes communes à tous les objets et les streams.

• Ce critère est évalué avec les grilles critériées présentées dans les tables qui suivent. Il est important de noter que, si ce critère contribue à l'acquis d'apprentissage « Qualité logicielle et tests », nous n'évaluons pas de manière directe la dextérité d'utilisation des outils de modélisation; mais, l'utilisation d'outils pour la modélisation aide au respect des notations UML.

• Le barème est donné à titre indicatif. Il y a 8 critères répartis dans les 2 tables ci-dessus (donc 8 lettres), chaque critère étant évalué en « a », « b », ou « c ». Chaque lettre peut être complétée avec un « + » ou un « - ». La note est calculée comme étant le minimum de 3 et de la somme (nombre de « a » × 1 + nombre de « b » × 0,5 + nombre de « + » × (0,2) + nombre de « - » × (-0,2)) multipliée par 3/8.

• Ce critère est évalué avec les grilles critériées présentées dans les tables qui suivent.

• Le barème est donné à titre indicatif. Il y a 6 critères majeurs répartis dans les 3 dernières tables et 3 critères d'outillage donnés dans la première table. Chaque critère est évalué en « a », « b », ou « c ». Chaque lettre peut être complétée avec un « + » ou un « - ». La note est ensuite calculée en trois temps :
  • premièrement, l'évaluation des critères majeurs : avec 6 critères majeurs, le premier terme est calculé comme le minimum de 4 et de la somme (nombre de « a » × 1 + nombre de « b » × 0,5 + nombre de « + » × (0,2) + nombre de « - » × (-0,2)) multipliée par 4/6 ;
  • deuxièmement, la somme des critères d'outillage : nombre de « c » × 0,5 + nombre de « b » × 0,2 ;
  • troisièmement, la note de la partie programmation est calculée comme étant le minimum de 4 et de la formule max(note critères majeurs - note critères d'outillage, 0).

• Ce critère est évalué avec la grille critériée présentée dans la table qui suit.

• Le barème est donné à titre indicatif. Il y a 2 critères dans la table. Chaque critère est évalué en « a », « b », ou « c ». Chaque lettre peut être complétée avec un « + » ou un « - ». La note est ensuite calculée comme étant le minimum de 1 et de la somme (nombre de « a » × 1 + nombre de « b » × 0,5 + nombre de « + » × (0,2) + nombre de « - » × (-0,2)) multipliée par 1/2.

• Ce critère est évalué avec la grille critériée présentée dans la table qui suit.

• Le barème est indiqué à titre indicatif. Il y a 3 critères (donc 3 lettres), chaque critère étant évalué en « a », « b », ou « c ». Chaque lettre peut être complétée avec un « + » ou un « - ». La note est calculée comme étant le minimum de 1 et de la somme (nombre de « a » × 1 + nombre de « b » × 0,5 + nombre de « + » × (0,2) + nombre de « - » × (-0,2)) multipliée par 1/3.

La présence en TP est évaluée comme suit : 0,1 point de présence par séance, soit 1 point sur l'ensemble du module ;

• Chaque étudiant et étudiante est évaluée sur l'ensemble des compétences acquises dans le module. L'étudiant ou étudiante se voit attribuer au sort un sujet comprenant un ensemble de questions auxquelles il ou elle répond aussitôt en suivant l'ordre de traitement des questions indiqué. L'étudiant et l'étudiante répond au maximum de questions dans le temps imparti. Les questions sont de niveaux de difficulté variés: 2 questions de premier niveau, 2 questions de niveau intermédiaire et 1 question d'un niveau plus avancé. Les connaissances et savoir-faire testés sont ceux listés dans des grilles d'évaluation données au fur et à mesure des séances.