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

 Portail informatique
  • Emploi du temps
  • Contenu
    • Avant le début du module
      Préparation de son environnement de travail
      Préparation de son environnement de travail
      • SSH, paire de clefs (publique, privée)

    • Séance 1
      Introduction
      Introduction et organisation du développement
      Grille d'auto-évaluation de la séance 1
      • Forge logicielle, GitLab, gestion de versions, Git
      • Entrée sous suivi de version, instantané d'un dépôt, zone de transit (staging area), validation (commit), états possibles d'une entrée, entrées ignorées
      • Clonage d'un dépôt, contenu du répertoire de travail, dépôt distant, tirer depuis un dépôt distant, pousser vers un dépôt distant
      • Branche, fusion de branches, étiquette, processus de travail avec branches pour les sprints et étiquettes pour les séances
    • HP 1 → 2
      (1 → 2)
      Estimé à 3h
    • Séance 2
      Spécification
      Spécification et préparation des tests de validation
      Grille d'auto-évaluation de la séance 2
      • « 4 + 1 » vues de Kruchten, vue « cas d'utilisation », rôle de la spécification, rôle de la préparation des tests de validation
      • Diagramme de cas d'utilisation, acteur, généralisation spécialisation entre acteurs, cas d'utilisation, lien de communication, généralisation spécialisation entre cas d'utilisation
      • Préparation des tests de validation, précondition, postcondition, relation entre les préconditions dans une généralisation spécialisation, relation entre les postconditions dans une généralisation spécialisation, test de validation d'un cas d'utilisation, table de décision
    • HP 2 → 3
      (2 → 3)
      Estimé à 3h
    • Séance 3
      Conception préliminaire
      Grille d'auto-évaluation de la séance 3
      • Vue « logique » des « 4 + 1 » vues de Kruchten, aspects statiques Versus dynamiques, rôle de la conception préliminaire
      • Diagramme de classes, classe, association, multiplicité, attributs d'instance / de classe / dérivés, opérations d'instance / de classe, classe d'association et transformation en une classe et deux associations, agrégation, classe abstraite, opération abstraite, généralisation spécialisation, redéfinition (override), liaison dynamique, surcharge (overload) (subsomption), principe de substitution de Liskov & Wing, Façade
      • Diagramme d'objets
      • Diagramme de séquence, participant, message, barre d'activation, ligne de vie, fragments, appel synchrone Versus asynchrone, recherche d'objet, création / suppression d'objet
      • Diagramme de communications, lien d'interaction, message, messages conditionnés / en séquence / imbriqués, recherche d'objet, création / suppression d'objet
    • HP 3 → 4
      (3 → 4)
      Estimé à 3h
    • Séance 4
      Conception détaillée
      Conception détaillée et préparation des tests unitaires
      Grille d'auto-évaluation de la séance 4
      • Rôle de la conception détaillée, rôle de la préparation des tests unitaires, dette technique
      • Raffinement de diagramme de classes, navigabilité, composition, agrégation
      • Diagramme de machine à états, type d'état, état initial / final / « en construction », « en destruction », événement, transition, condition, action, transition implicite
      • Fiche de classe, traduction des associations en attributs, référence, traduction des agrégations Versus compositions, visibilité, encapsulation, opération accesseur, traduction des attributs dérivées, traduction des classes d'association, traduction des diagrammes d'interaction en algorithmes, traduction des diagrammes de machine à états
      • Invariant de classe, programmation défensive avec vérification des préconditions, programmation par assertion avec l'opération invariant
      • Tests unitaires d'une opération, vérification de la postcondition et de la levée d'exception, expression de la postcondition avec les attributs prime, table de décision des tests unitaires d'une opération
    • HP 4 → 5
      (4 → 5)
      Estimé à 3h
    • Séance 5
      Programmation outillée
      Grille d'auto-évaluation de la séance 5
      • Programmation outillée, construction de logiciel avec Maven, programmation et exécution des tests avec JUnit
      • Héritage, transtypage (implicite vers le haut, explicite vers le bas), redéfinition de méthodes, liaison tardive, type formel, type actuel, visibilité des attributs et des méthodes, classe abstraite, interface
      • Polymorphisme, classe paramétrée (generics), paramètre de type
      • Énumération, annotations
      • Collections, bibliothèque, interfaces, classes concrètes, algorithmes, listes, dictionnaires, méthodes equals et hashCode, parcours de collections
    • HP 5 → 6
      (5 → 6)
      Estimé à 3h
    • Séance 6
      Livraison Sprint 1
      Livraison du premier sprint
      Grille d'auto-évaluation de la séance 6
      • Flot d'exécution normale versus flot de gestion des erreurs, détection d'une situation anormale, région gardée, traitement d'une situation anormale par compensation et poursuite, par transformation du type d'exception, par arrêt franc.
      • Lever une exception avec throw new ClasseException(message), relayer une exception avec throws, traiter une exception avec le bloc try—catch, finally.
      • Erreur versus exception, exceptions sous contrôle (checked, y compris les exceptions applicatives) et hors contrôle (unchecked, RuntimeException).
      • Programmation des tests avec JUnit (vrai positif, vrai négatif, faux positif et faux négatif), annotations @BeforeClass, @Before, @Test, @After et @AfterClass.
      • Exception dans les tests, @Test(expected=ClasseException.class).
    • HP 6 → Sprint 1
      (6 → Sprint 1)
      Estimé à 3h
      • Livrer le vendredi 24 mars avant 23h55
    • Séance 7
      Qualité et idiomes
      Qualité du code et idiomes (patrons d'implémentation)
      Grille d'auto-évaluation de la séance 7
      • Analyse statique de code, aide avec FindBugs, Javadoc, aide avec Checkstyle
      • Idiome, patron d'implémentation
      • Idiomes JAVA, méthodes communes à tous les objets, equals avec hashCode, toString avec les cas particuliers de l'association bidirectionnelle et de l'énumération
    • HP
      (7 → 8)
      Estimé à 3h
    • Séance 8
      Streams et Optional
      Lambda expressions, Streams et Optional
      Grille d'auto-évaluation de la séance 8
      • Lambda expressions, classe anonyme, interface fonctionnelle, syntaxe d'une lambda expression (types des arguments explicites ou inférés, corps formé d'un bloc ou d'une expression), contexte d'exécution, référence de méthode, syntaxe et type d'une référence d'une méthode, interfaces fonctionnelles standard.
      • Manipulation des collections avec les Streams, paradigme de programmation map/reduce, pipeline, stream, évaluation tardive, début / traitement intermédiaire / terminaison du pipeline.
      • Gestion des références null avec Optional.
    • HP
      (8 → 9)
      Estimé à 3h
    • Séance 9
      Qualité et patrons de conception
      Qualité du modèle UML et patrons de conception
      Grille d'auto-évaluation de la séance 9
      • Qualité de modèle UML : correction sémantique (well-formedness), cohérence (consistency), complétude (completeness), cohérence entre diagrammes, cohérence avec le code, couplage et cohésion (fonctionnelle, fortuite)
      • Patrons de conception : nom / problème / solution / conséquences, patrons créationnels (Singleton), patrons structuraux (Façade, Composite), patrons comportementaux (Stratégie, Publier — Souscrire, Observateur — Observable)
    • HP
      (9 → 10)
      Estimé à 3h
    • Séance 10
      Livraison Sprint 2
      Livraison du Sprint 2
    • HP 10 → Sprint 2
      (6 → Sprint 1)
      Estimé à 3h
      • Livrer le vendredi 14 avril avant 23h55
  • Cahier des charges
  • Auto-évaluation
  • Liste récap. tâches/séance
  • Planif. oraux de valid.
  • Entraînement au CF2
  • Aides

Fiche programme du module

Objectifs du module : À l'issue du module CSC4102, les étudiants sont capables :

Prérequis du module :

Avant le module CSC4102, les étudiants sont capables :
  • en ce qui concerne les outils de développement et de gestion de versions :
    • 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.
  • en ce qui concerne le développement informatique et la gestion de projet :
    • 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.
  • en ce qui concerne la modélisation orientée objet illustrée avec le diagramme de classes UML :
    • 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).
  • en ce qui concerne la programmation orientée objet illustrée avec le langage JAVA :
    • 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.
  • Patron de conception MVC :
    • nommer le patron de conception MVC avec ses composantes dans les cas d'utilisation qu'ils ont rencontrés : interface graphique et application Web.

Préconceptions (en anglais, misconceptions) combattues pendant le module :
  • PRÉ—C 1 : « Je n'ai pas besoin d'une ingénierie du logiciel »

    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. »

  • PRÉ—C 2 : « Je programme sans spécifier »

    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.

  • PRÉ—C 3 : « Le credo `système d'information externalisé et à la demande' implique `peu de besoins en analyse métier' »

    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.

  • PRÉ—C 4 : « Je n'ai pas besoin de notation (comme UML) pour modéliser/spécifier »

    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.

  • PRÉ—C 5 : « Avec les méthodes agiles comme eXtreme Programming, je n'ai plus besoin de conception » implique « peu de besoins en conception et on va directement dans le code »

    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.
  • PRÉ—C 6 : « Dans une startup, je ne me préoccupe pas de la qualité logicielle, je livre le plus vite possible »

    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.

  • PRÉ—C 7 : « Un éditeur de texte comme emacs ou un environnement de développement comme Eclipse suffisent pour l'activité de programmation »

    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.

  • PRÉ—C 8 : « Avec les générateurs de code, la programmation n'est plus un problème »

    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.

  • PRÉ—C 9 : « Un éditeur de texte comme emacs ou un environnement de développement comme Eclipse suffisent pour l'activité de programmation » (bis)

    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.

  • PRÉ—C 10 : « Des rudiments sur JAVA, ça suffit »

    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.

Critères d'évaluation (certificative) du module :

Séquencement

Telecom SudParis
Institut Polytechnique de Paris

9, rue Charles Fourier
F-91011 Evry Cedex France

19, Place Marguerite Perey
F-91120 Palaiseau Cedex France

Ⓒ 2020–2023 Télécom SudParis