Informatique de BaseInformatique 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)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)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 CoursContenu du Cours

• Partie théorique (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ésFacteurs de Difficultés

Complexité du problème

Problème mal défini

Travail en équipe

Facteurs de Difficultés:Facteurs de Difficultés:Complexité du ProblèmeComplexité 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èmeComplexité du Problème::SolutionsSolutions

• Conceptualisation (description des

concepts)

• Abstraction (ommission des détails)

• Décomposition/structuration

• Travail en équipe

• Elaboration des tests

Facteurs de Difficultés:Facteurs de Difficultés:Problème mal définiProblè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éfiniProblème mal défini: : SolutionSolutionss

• Spécification claire/précise du problème

• Relecture de la specification du problème

Facteurs de Difficultés:Facteurs de Difficultés:Travail en équipeTravail 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 équipeTravail en équipe: : SolutionsSolutions

• 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 coursPlan du cours

• Techniques de

– Conceptualisation (modélisation) et

Abstraction

– Structuration

– Modularité

– Spécification

– Révision de spécification

– Tests

Techniques de Techniques de Conceptualisation Conceptualisation

de Problèmesde Problèmes

Conceptualiser = ?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:Conceptualisation du Problème:EtapesEtapes

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:Conceptualisation du Problème:Décrire les Limites et le Contexte 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: Diagramme de contexte: AgentsAgents

• 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: Diagramme de contexte: InteractionsInteractions

• 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:Diagramme de Contexte:Exemple - Ascenseur (1)Exemple - Ascenseur (1)

Programmede contrôled'ascenseur

Utilisateur(s)d'ascenseur

Utilisateur(s)d'ascenseur

Moteur

Portes

Cage

Appeler

DemanderEtage Démarrer/Arrêter

Monter/Descendre

Ouvrir/Fermer

Entrer/Sortir

Etage

Diagramme de Contexte:Diagramme de Contexte:Exemple - Ascenseur (2)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: Diagramme de contexte: InteractionsInteractions

• 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:Diagramme de Contexte:RemarquesRemarques

• 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:Conceptualisation du Problème:Décrire les Fonctionnalités PrincipalesDé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: Diagramme Fonctionnel: FonctionsFonctions

• 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:Diagramme Fonctionnel:Exemple - AscenseurExemple - Ascenseur

Aller ChercherUtilisateur

Aller DéposerUtilisateur

Appeler(EtageAppel)

EtageCage

Démarrer(sens)

DemanderEtage(EtageDemandé)

EtageCageDémarrer(sens)

Arrêter

Arrêter

Ouvrir

Fermer

2 fonctions principales:

Ouvrir

Diagramme Fonctionnel:Diagramme Fonctionnel:Exemple - Ascenseur - Description objectif des fonctionsExemple - 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:Diagramme Fonctionnel:RemarquesRemarques

• 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: Conceptualisation du Problème: Décrire les DonnéesDé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:Décrire les données:RemarquesRemarques

• 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 de données:Types ÉnumérationTypes É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:Types de données:Séquences/suitesSé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:Types de données:EnsemblesEnsembles

• 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 Techniques de Structuration de Problèmes Problèmes

Décomposition des fonctions

Modularité

Structuration du problème: Structuration du problème: Décomposition des FonctionsDécomposition des Fonctions

Décomposition des FonctionsDé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 Diagramme de Décomposition Fonctionnelle: Exemple - Ascenseur (1)Fonctionnelle: Exemple - Ascenseur (1)

• Reduire le problème à des problèmes plus simple:

Aller ChercherUtilisateur

Déterminer Sens Appel

EnvoyerOrdre

Demarrage

EnvoyerOrdreArrêt

OuvrirPortes

Diagramme de Décomposition Diagramme de Décomposition Fonctionnelle: Exemple - Ascenseur (2)Fonctionnelle: Exemple - Ascenseur (2)

Aller DéposerUtilisateur

Déterminer Sens Dépôt

EnvoyerOrdre

Demarrage

EnvoyerOrdreArrêt

OuvrirPortes

FermerPortes

Diagramme de Décomposition Diagramme de Décomposition Fonctionnelle: RemarquesFonctionnelle: 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-Diagramme Fonctionnel pour les sous-fonctions: Exemple - Ascenseur (1)fonctions: Exemple - Ascenseur (1)

Aller ChercherUtilisateur

Appeler(EtageAppel)

EtageCage

Déterminer Sens Appel

EtageAppel

EtageCagesens

EnvoyerOrdre

Demarrage

Démarrer(sens)

EnvoyerOrdreArrêt

ÉtageAppel

EtageCageArrêter Ouvrir

PortesOuvrir

Démarrer(sens)

Arrêter

Ouvrir

sens

Diagramme Fonctionnel pour les sous-Diagramme Fonctionnel pour les sous-fonctions: Exemple - Ascenseur (2)fonctions: Exemple - Ascenseur (2)

Aller DéposerUtilisateur

DemanderEtage(EtageDemandé)

EtageCage

Déterminer Sens Dépôt

EtageDemandé

EtageCagesens

EnvoyerOrdre

Demarrage

Démarrer(sens)

EnvoyerOrdreArrêt

EtageDemandé

EtageCageArrêter

OuvrirPortes

Ouvrir

Démarrer(sens)

Arrêter

Ouvrir

sens

Fermer

FermerPortes

Fermer

Diagramme Fonctionnel pour les sous-Diagramme Fonctionnel pour les sous-fonctions: Remarquesfonctions: 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 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: Diagramme fonctionnel de flux: Exemple AscenseurExemple Ascenseur

Déterminer Sens Appel

EtageAppel

EtageCagesens

Envoyer Ordre Demarrage

Démarrer(sens)

EnvoyerOrdre Arrêt

ÉtageAppel

EtageCageArrêter

OuvrirPortes

Ouvrir

Enchaînement (ordre) des fonctions

Aller Chercher Utilisateur

=

Diagramme fonctionnel de flux: Diagramme fonctionnel de flux: RemarquesRemarques

• On peut avoir une itération sur une sous-fonction

Diagramme fonctionnel de flux: Diagramme fonctionnel de flux: Programme CorrespondantProgramme 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: Programme Correspondant: Exemple AscenseurExemple 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: Programme Correspondant: Exemple AscenseurExemple 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)begin

Démarrer(s);end

EnvoyerOrdreArrêt(ea: ETAGE) var ec: ETAGE;begin

RecevoirEtageCage(ec);while (ec <> ea) do begin

AttendreUneSeconde;RecevoirEtageCage(ec);

endArrêter;

end

var int EtageCage;SENS Sens;

begin RecevoirEtageCage(EtageCage);DéterminerSensAppel(EtageAppel,

EtageCage, Sens);EnvoyerOrdreDémarrage(Sens);EnvoyerOrdreArrêt(EtageAppel);OuvrirPortes;

end;

Techniques de Structuration: Techniques de Structuration: ModularitéModularité

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: Modules: Qualités attendues (1)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: Modules: Qualités attendues (2)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 ModulesExemples 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

– Exemple:

• Unit pour traiter des matrices (transposer,…)

Gestion du MoteurGestion du Moteur

Gestion des PortesGestion des Portes

Gestion des Requêtes UtilisateurGestion des Requêtes Utilisateur

Modules: Modules: Exemple - AscenseurExemple - Ascenseur

Aller DéposerUtilisateur

DemanderEtage(EtageDemandé)

EtageCage

Déterminer Sens Dépôt

EtageDemandé

EtageCagesens

EnvoyerOrdre

Demarrage

Démarrer(sens)

EnvoyerOrdreArrêt

EtageDemandé

EtageCageArrêter

OuvrirPortes

Ouvrir

Démarrer(sens)

Arrêter

Ouvrir

sens

Fermer

FermerPortes

Fermer

Déterminer Sens Appel

EtageAppel

EtageCagesens

Aller ChercherUtilisateur

Appeler(EtageAppel)

EtageCage

Démarrer(sens)

Arrêter

Ouvrir

Description des interactions entre Description des interactions entre modules: Diagramme de Contextemodules: Diagramme de Contexte

Utilisateur(s)d'ascenseur

Moteur

Portes

Cage

Appeler

DemanderEtage Démarrer/Arrêter

Ouvrir/Fermer

Etage

Gestion des requêtes

Utilisateurs

Gestion du Moteur

Gestion des Portes

EnvoyerOrdreDémarrage

EnvoyerOrdreArrêt

Etage

OuvrirPortes/FermerPortes

Description des interactions entre Description des interactions entre modules: Diagramme de Contextemodules: 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