Informatique de Base Michaël Petit 2ème Candi Sc.Eco. Option Info. Année 2000-2001 mpe@info.fundp.ac.be Bureau 202a, Institut d'Informatique

Introduction (1) Les autres cours de programmation en candi insistent sur l ’importance: d ’une méthode de programmation (raisonnement rigoureux) de conceptualiser / modéliser le problème avant d ’implémenter de spécifier les programmes de prouver / vérifier que les programmes sont corrects Mais les problèmes traités dans ces cours sont: de petite taille (1 ou 2 pages de programme) clairement définis souvent résolus individuellement  La nécessité de méthode, spécification et preuve peut ne pas être directement évidente

Introduction (2) Dans d ’autres situations, les problèmes seront plus difficiles à résoudre car: plus complexes mal définis résolus en équipe Objectifs du cours Faire ressentir l ’importance de structurer, conceptualiser et spécifier le problème Apprendre des techniques simples pour approcher les problèmes complexes Intitulé Informatique de Base Développement d ’Applications Informatiques en Equipe

Contenu du Cours Partie théorique (15h) Travail Pratique (15h) Eléments de méthodes/techniques utiles pour la résolution (programmation) de problèmes informatiques complexes Travail Pratique (15h) Réalisation d ’un programme de taille importante Travail en équipe Rapports à remettre contenu technique (spécifications, programmes,…) contenu évaluatif (problèmes rencontrés, évaluation des techniques,…) Déroulement en alternance ( 1/2) Evaluation TP = 50% Examen (théorie + application) = 50%

Facteurs de Difficultés Complexité du problème Problème mal défini Travail en équipe

Facteurs de Difficultés: Complexité du Problème Complexité des données calcul de différence de dates versus représentation des composants d'une TV Complexité des fonctionnalités gestion carnet d'adresses versus système d'assistance au pilotage d'un avion Taille (nombre de données/fonctions) gestion carnet d'adresses personnel vs gestion des patients d'un hopital Hétérogénéité gestion de videothèque vs programme de paye

Complexité du Problème: Solutions Conceptualisation (description des concepts) Abstraction (ommission des détails) Décomposition/structuration Travail en équipe Elaboration des tests

Facteurs de Difficultés: Problème mal défini Description incomplète ex: fonctionnalité manquante Description d'une solution au lieu du problème lui-même en dit trop (sur la solution) et pas assez (sur le problème) ex: décrire comment trier une liste au lieu de dire qu'elle doit être triée Description ambiguë/imprécise plusieurs interprétations possibles ex: "plus petit que" Description erronée contient des affirmations fausse ou incohérentes ex: "une nombre premier est divisible…", "4 est un nombre premier"

Problème mal défini: Solutions Spécification claire/précise du problème Relecture de la specification du problème

Facteurs de Difficultés: Travail en équipe Compréhension différente du problème  solutions incompatibles Résolution individuelle de parties séparées du problème  chacun a une vue partielle Chacun a tendance à penser que sa solution est la meilleure  essaye d'imposer

Travail en équipe: Solutions Conceptualisation initiale du problème et partage de cette conceptualisation Spécification précise du problème et de sa solution Relecture de la specification du problème et de la solution Elaboration de jeux de tests pour l'ensemble du programme

Plan du cours Techniques de Conceptualisation (modélisation) et Abstraction Structuration Modularité Spécification Révision de spécification Tests

Techniques de Conceptualisation de Problèmes

Conceptualiser = ? Identifier et définir les concepts du problème abordé Pour bien le comprendre Afin d'élaborer une solution adéquate

Conceptualisation du Problème: Etapes 1.Identifier et décrire les limites et le contexte du programme 2. Identifier et décrire les fonctionnalités (procédures) principales 3. Identifier et décrire les données (variables et types) manipulées par le programme

Conceptualisation du Problème: Décrire les Limites et le Contexte Objectif: Décider ce qui est dans le programme et ce qui n'y est pas Montrer ce qui peut influencer le comportement du programme ou être influencé par le programme Outil: diagramme de contexte graphe Nœuds = Agents Arcs = Interactions Description des agents et interactions

Diagramme de contexte: Agents Agent central le programme à créer vu comme une boîte noire (abstraction) Agents périphériques tout ce qui a une interaction avec le programme mais n'en fait pas partie vus comme des boîtes noires (abstraction). Types d'agents humains (utilisateurs, …) logiciels (autres programmes existants) matériels (machines, appareils,…)

Diagramme de contexte: Interactions Programme - utilisateur: choix de fonctionnalité à exécuter données introduites résultats affichés Programme - autre programme: données reçues ou fournies appels de fonctionnalités du programme ou par le programme Programme - machine, appareil événements générés ou données envoyées par la machine ordres ou données envoyés à la machine Eventuellement identifier les interactions entre les agents périphériques

Diagramme de Contexte: Exemple - Ascenseur (1) Cage Entrer/Sortir Monter/ Descendre Utilisateur(s) d'ascenseur Etage Appeler Moteur Programme de contrôle d'ascenseur DemanderEtage Démarrer/ Arrêter Ouvrir/ Fermer Portes

Diagramme de Contexte: Exemple - Ascenseur (2) Description agents: Programme de contrôle d'ascenseur: le programme à réaliser. En fonction des appels et demandes d'étage de l'utilisateur, il commande le moteur et les portes pour y répondre. Moteur: appareil électrique qui peut tourner dans le sens des aiguilles d'une montre, ou dans le sens inverse. Se met à tourner dans le sens demandé par le programme sur ordre de celui-ci. Description interactions: Monter: lorsque le moteur tourne dans le sens des aiguilles d'une montre, il produit une effet sur la cage (il la fait monter d'un étage à la fois) Appeler: l'utilisateur d'ascenseur appuie sur le bouton pour demander au contrôleur la venue de la cage à un étage donné. EtageCage: la cage indique au contrôleur l'étage auquel elle se trouve

Diagramme de contexte: Interactions Pour chaque interaction: lui donner un nom si c'est un échange de données, identifier le type de données si c'est appel de procédure, un ordre donné ou un événement, indiquer si des données sont passées le type des données Exemple: EtageCage: ETAGE ETAGE = Entier compris entre -2 et 5 Appeler(EtageAppel: ETAGE) DemanderEtage(EtageDemandé: ETAGE) Ouvrir (ordre d'ouverture des portes) n'a pas de donnée associée Démarrer(sens: {Haut,Bas,Non})

Diagramme de Contexte: Remarques Programmes classiques: pas d'agents matériels programme + utilisateur(s) + éventuellement programmes existants Un agent peut représenter une personne physique ou un rôle joué par une personne physique dans ses interactions avec le programme Exemple: programme de paye des employés Encodeur des barèmes Utilisateur normal (consulte liste employés)

Conceptualisation du Problème: Décrire les Fonctionnalités Principales Objectif: Décrire ce que le programme doit faire en réponse aux interactions de son environnement (agents périphériques) Quelles données produire, événements générer et appels de procédures envoyer à l'environnement en fonction des demandes, événements ou données reçues de celui-ci Fonctionnalité +- = procédure Outil: Diagramme fonctionnel. Par ex. IDEF0, SADT, ... Graphique nœuds: fonctionnalité (ou fonction) et données (ou événements) arc donnée  fonction: donnée utilisée par la fonctionnalité (paramètre en entrée) arc fonction  donnée: donnée produite par la fonctionnalité (paramètre en sortie)

Diagramme Fonctionnel: Fonctions Identifier les données en entrée et en sortie = décrire une entête de procédure Fonctionnalité principales = ce qui est visible à l'extérieur du programme déclenché à la demande d'un agent périphérique et/ou produit un effet à destination d'un agent périphérique Décrire l'objectif de chaque fonction (comment elle transforme les données) en français

Diagramme Fonctionnel: Exemple - Ascenseur 2 fonctions principales: Démarrer(sens) Appeler(EtageAppel) Aller Chercher Utilisateur Arrêter Ouvrir EtageCage DemanderEtage (EtageDemandé) Fermer Aller Déposer Utilisateur Démarrer(sens) EtageCage Arrêter Ouvrir

Diagramme Fonctionnel: Exemple - Ascenseur - Description objectif des fonctions Fonction Aller Chercher Utilisateur: Sur base d'un étage où l'utilisateur a effectué un appel et de l'étage où se trouve actuellement la cage, émettre un ordre de démarrage à destination du moteur (indiquant le sens de rotation adéquat). Lorsque l'étage est atteint par la cage, emettre un ordre d'arrêt au moteur et un ordre d'ouverture des portes. Fonction Aller Déposer Utilisateur: Sur base d'un étage où l'utilisateur veut aller et de l'étage où se trouve actuellement la cage, émettre un ordre de fermeture des portes, puis un ordre de démarrage à destination du moteur (indiquant le sens de rotation adéquat). Lorsque l'étage est atteint par la cage, emettre un ordre d'arrêt au moteur, puis un ordre d'ouverture des portes.

Diagramme Fonctionnel: Remarques Les données identifiées dans le diagramme fonctionnel doivent correspondre aux données identifiés dans le diagramme de contexte dans les interactions On utilisera le même nom pour faire la correspondance

Conceptualisation du Problème: Décrire les Données Objectif: Préciser pour chaque donnée identifiée dans les diagrammes précédents son type Décrire les données manipulées (reçues ou produites) par le programme Outil: Exemples de yypes de données simples et connus: entiers, réels, booléens, rationnels, … énumérations de valeurs: ex: SENS={Haut,Bas,Non} , couleur={noir,jaune,rouge} Intervalles: ex: [-2,10] type construits (complexes): séquence/suite record ensemble ... . . . . . .

Décrire les données: Remarques Attention à la différence entre variable et type Structure logique (versus physique) voir cours Baudouin Le Charlier pour la conceptualisation, utiliser des structures logiques! ex: Pile et pas liste chaînée Au niveau d'abstraction adéquat ne doit pas nécessairement spécifier toute la structure de données

Types de données: Types Énumération Définition: Type = Ensemble de valeurs Variable de ce type à tout moment une et une seule valeur parmi cet ensemble Utiliser quand: On connaît toutes les valeurs possibles valeurs en nombre fixe et limité valeurs ne correspondent pas à celles d'un type simple connu (booléen, réel,…) Syntaxe: par exemple: SENS={Haut,Bas,Non}

Types de données: Séquences/suites Définition: Type = ensemble des suites (éventuellement vide) dont chacune des valeurs est d'un type donné Une variable de ce type contient une séquence (éventuellement vide) de valeurs Utiliser quand: l'ordre est important des doubles peuvent apparaître on veut manipuler des sous-séquences … Syntaxes possibles LISTE-LIVRES = Suite[LIVRE] ... a1 a2 a3 an ai : LIVRE (pour tout i)

Types de données: Ensembles Définition: Type = ensemble des ensembles qui peuvent être formés à partir de zéro, une ou plusieurs valeurs d'un autre type donné Variable de ce type contient un ensemble (éventuellement vide) qui contient des valeurs du type donné Utiliser quand: l'ordre entre les valeurs n'est pas important des doubles ne peuvent pas apparaître on veut tester l'appartenance, l'inclusion, ... … Syntaxes possibles ENSEMBLE-LIVRES = Ens[LIVRE]

Techniques de Structuration de Problèmes Décomposition des fonctions Modularité

Structuration du problème: Décomposition des Fonctions

Décomposition des Fonctions Objectif: décomposer le(s) problème(s) complexe(s) en problèmes plus simples diviser pour régner = décomposer une procédure en sous-procédures les sous-problèmes rapprochent chacun de la solution globale Outils: Diagramme de décomposition fonctionnelle montrer le lien entre une fonction et une sous-fonction Diagramme fonctionnel pour chaque sous fonction Diagramme fonctionnel de flux montrer comment les résultats produits par une sous-fonction sont utiles pour la suivante

Diagramme de Décomposition Fonctionnelle: Exemple - Ascenseur (1) Reduire le problème à des problèmes plus simple: Aller Chercher Utilisateur Déterminer Sens Appel Envoyer Ordre Demarrage Envoyer Ordre Arrêt Ouvrir Portes

Diagramme de Décomposition Fonctionnelle: Exemple - Ascenseur (2) Aller Déposer Utilisateur Fermer Portes Déterminer Sens Dépôt Envoyer Ordre Demarrage Envoyer Ordre Arrêt Ouvrir Portes

Diagramme de Décomposition Fonctionnelle: Remarques Trouver un bon équilibre entre les sous-fonctions pas décomposer si trivial décomposer en fonction de complexité comparable Une sous-fonction peut être réutilisée dans plusieurs fonctions Par exemple: Ouvrir Portes On peut réappliquer la décomposition aux sous-fonctions Décompositions fréquentes: entrée de données / Traitement / Affichage identifier des fonctions qui portent sur les mêmes données (ex: opérations sur une pile)

Diagramme Fonctionnel pour les sous-fonctions: Exemple - Ascenseur (1) Appeler (EtageAppel) Démarrer(sens) Aller Chercher Utilisateur Arrêter Ouvrir EtageCage EtageAppel Envoyer Ordre Demarrage Déterminer Sens Appel Démarrer (sens) sens sens EtageCage ÉtageAppel Envoyer Ordre Arrêt Ouvrir Portes Arrêter Ouvrir EtageCage

Diagramme Fonctionnel pour les sous-fonctions: Exemple - Ascenseur (2) Fermer DemanderEtage (EtageDemandé) Démarrer(sens) Aller Déposer Utilisateur Arrêter Ouvrir EtageCage EtageDemandé Envoyer Ordre Demarrage Déterminer Sens Dépôt Démarrer (sens) sens sens EtageCage Ouvrir Portes EtageDemandé Envoyer Ordre Arrêt Ouvrir Arrêter EtageCage Fermer Portes Fermer

Diagramme Fonctionnel pour les sous-fonctions: Remarques Les entrées de la fonction décomposée doivent correspondre aux entrées de certaines sous-fonctions Idem pour les sorties Pour chaque sous-fonction décrire l'objectif typer les données (voir Conceptualisation de problèmes - diagramme fonctionnel)

Diagramme fonctionnel de flux Montrer dans quel ordre les sous-fonctions ont lieu dans le cadre de l'exécution de la fonction comment les résultats produits par une sous-fonctions sont utilisés par la sous-fonction suivante Liens: enchaînement des fonctions liaison entre les données en sortie de sous-fonctions et les données en entrée d'autres

Diagramme fonctionnel de flux: Exemple Ascenseur Aller Chercher Utilisateur Enchaînement (ordre) des fonctions EtageAppel = Déterminer Sens Appel EtageCage sens Envoyer Ordre Demarrage Démarrer (sens) ÉtageAppel Envoyer Ordre Arrêt Arrêter EtageCage Ouvrir Portes Ouvrir

Diagramme fonctionnel de flux: Remarques On peut avoir une itération sur une sous-fonction

Diagramme fonctionnel de flux: Programme Correspondant Les fonctions décomposée est une procédure Les sous-fonctions sont des sous-procédures de celle-ci Les données en entrée et sortie (E/S) de la fonction sont des paramètres de la procédure ou des variables globales L'enchaînement est représenté par le "flux de contrôle du programme" appel des sous-procédures dans l'ordre spécifié en passant les paramètres liés Les données en E/S des sous-fonctions sont des paramètres des sous-procédures Les données liées qui ne sont pas des E/S de la fonction sont des variables internes de la procédure

Programme Correspondant: Exemple Ascenseur Hypothèses: La donnée "EtageCage" peut être obtenue en appelant une procédure (fournie par l'agent "Cage") qui renvoie à la demande l'étage où se trouve la cage Le moteur peut être commandé (démarré ou arrêté) par des appels de procédures (fournies par l'agent "Moteur") Les portes peuvent être commandées (ouvertes ou fermées) par des appels de procédures (fournies par l'agent "Portes")

Programme Correspondant: Exemple Ascenseur Procedure AllerChercherUtilisateur(EtageAppel: ETAGE) Procedure DéterminerSensAppel(ea, ec: ETAGE; var s: SENS) begin if (ea = ec) then s=Non else if (ea < ec) then s:=Bas else s:=Haut; end; Procedure EnvoyerOrdreDémarrage(s: SENS) Démarrer(s); end EnvoyerOrdreArrêt(ea: ETAGE) var ec: ETAGE; RecevoirEtageCage(ec); while (ec <> ea) do AttendreUneSeconde; Arrêter; var int EtageCage; SENS Sens; begin RecevoirEtageCage(EtageCage); DéterminerSensAppel(EtageAppel, EtageCage, Sens); EnvoyerOrdreDémarrage(Sens); EnvoyerOrdreArrêt(EtageAppel); OuvrirPortes; end;

Techniques de Structuration: Modularité

Modularité Définition (Larousse): Modulaire = constitué d'un ensemble de modules Module = Unité fonctionnelle d'équipement susceptible d'être utilisée avec une autre Utilisation pour les problèmes complexes: Un problème/programme complexe peut être découpé en modules Les modules seront combinés pour obtenir la solution complète On peut s'intéresser à chaque module séparément: l'un après l'autre en même temps, par des personnes différentes Dans notre cas: un module = un groupement de fonctions et de données identifiées lors de la décomposition fonctionnelle

Modules: Qualités attendues (1) Simplicité et homogénéité: maximiser la cohésion interne Les choses groupées dans un module ont un rapport évident entre elles Les données et fonctions goupées à l'intérieur d'un sous système sont fortement "liées". Par exemple: Grouper une donnée et les fonctions qui portent dessus Grouper une fonction et ses sous-fonctions Grouper des données dont les valeurs dépendent l'une de l'autre ...

Modules: Qualités attendues (2) Indépendance: minimiser le couplage Les choses qui sont dans des modules différents ont peu de lien entre elles Les données et fonctions de sous-systèmes différents sont faiblement liés Par exemple: Séparer données et fonctions qui ne portent pas sur cette donnée Séparer des fonctions qui n'ont rien à voir l'une avec l'autre (l'une n'est pas une sous-fonction de l'autre, l'une n'utilise pas de résultat de l'autre,…) Séparer des données qui ne sont pas liées

Exemples de Modules Type abstrait de données = Groupement dans une unité d'un type de donnée des opérations qui agissent sur les données de ce type Exemple: PILE[X] Add, Remove,… Unit Pascal = Groupement dans une unité de fonctions qui peuvent être utilisées par un programme des sous-fonctions nécessaires pour implémenter ces fonctions des données internes utiles pour ces implémenter ces fonctions Unit pour traiter des matrices (transposer,…)

Modules: Exemple - Ascenseur Gestion des Requêtes Utilisateur Fermer Gestion du Moteur DemanderEtage (EtageDemandé) Démarrer(sens) Aller Déposer Utilisateur Arrêter Envoyer Ordre Arrêt EtageCage EtageDemandé Ouvrir Arrêter Démarrer(sens) EtageCage Appeler (EtageAppel) Aller Chercher Utilisateur Arrêter EtageCage Ouvrir Envoyer Ordre Demarrage Démarrer (sens) sens EtageDemandé Déterminer Sens Dépôt sens EtageCage EtageAppel Déterminer Sens Appel sens Gestion des Portes EtageCage Ouvrir Portes Ouvrir Fermer Portes Fermer

Description des interactions entre modules: Diagramme de Contexte Cage Etage Utilisateur(s) d'ascenseur Etage Appeler Moteur EnvoyerOrdreDémarrage DemanderEtage Démarrer/ Arrêter Gestion des requêtes Utilisateurs Gestion du Moteur EnvoyerOrdreArrêt OuvrirPortes/ FermerPortes Gestion des Portes Portes Ouvrir/ Fermer

Description des interactions entre modules: Diagramme de Contexte Un module = un agent Les interactions qui reliaient un agent "périphérique" (externe au programme) restent mais sont rattachées à un agent (module) interne au programme Des nouvelles interactions internes au programme montrent: les appels de procédures entre modules les données qui passent d'un module à l'autre