dimanche 27 janvier 2008

Complexité, un mot vide de sens, ou trop plein de vide ?

Etonnant chez des informaticiens !

Alors, lisons les auteurs ...
J-P Delaye dans son beau livre, Les inattendus mathématiques, Belin, page 35, nous parle de la "complexité de Kolmogorov"
En sciences éco j'avais appris le "test de Kolmogorov-Smirnov".

"La complexité de Kolmogorov d'un objet est la taille du plus petit programme d'ordinateur qui spécifie complètement cet object. Pour un dessin ou une peinture, c'est la taille du plus petit programme qui permet de reproduire l'image de l'oeuvre sans rien perdre de ce que nous en percevons. L'idée de Kolmogorov est simplement de rendre formelle l'intuition commune que "le simple est ce qui se dit en peu de mots" et "le complexe est ce qu'on ne réussit pas à comprimer quoi qu'on fasse."

Je vous rappelle que nous distinguons :
- le complexe, intrinsèque au problème, à l'objet
- le compliqué : utiliser la numération romaine est introduire de la complication dans les opérations arithmétiques (les programmes), utiliser des notations non formelles est introduire des complications, des discussions inutiles dans la conception de systèmes automatisés. (voir mes questions de Projet Tuteuré)


Et citons de nouveau Nicolas (cité dans le poly spec1) :

"Ce qui se conçoit bien s'énonce clairement Et les mots pour le dire arrivent aisément."

Nicolas Boileau, L'art poétique, Chant I.


samedi 26 janvier 2008

"faux et usage de faux et atteinte au système de traitement informatisé de données"

Dernières nouvelles :
"L'enquête préliminaire ouverte jeudi après-midi par le parquet de Paris est étendue aux faits de "faux et usage de faux et atteinte au système de traitement informatisé de données", visés par la plainte de la banque. Elle avait été ouverte à la suite de la plainte contre X déposée par un petit porteur pour "escroquerie, abus de confiance, faux et usage de faux". La brigade financière est saisie de cette enquête. "

et le blog qui nous amène au coeur du comment. On comprend un peu ... Excel, mots de passe, procédures, etc. Enfin des tas de choses qui font partie d'un cours de génie logiciel et de sécurité.

Lire aussi ici
Lire l'article du Monde

La modélisation et la vérification des procédures de sécurité utilisent entre autres les techniques que nous étudions dans ce module.

Pour ceux qui ont raté le premier cours

ou qui y faisaient autre chose qu'écouter et prendre des notes
et qui consultent ce bloc-notes, voici ce que j'ai traité :

- la prise en compte d'une "variable d'état" dans un schéma relationnel n-aire, exemple des commandes (livrée, facturée, réglée, en contentieux ...) avec un automate
- écriture de la fonction de transition d'états (fonction si automate déterministe !)
- diagramme de transition d'état simple, état initial, final
- étiqueté par événements
transitions : ETAT * EVENEMENT +-> ETAT
- avec gardes (on verra qu'en B événementiel, un événement est modélisé comme une opération gardée. Revoir l'axiome de la garde vs celui de la précondition. En DS je demandais celui du choix indéterministe. [CHOICE S OR T] I <=> [S] I & [T] I
- avec sorties, Mealy et Moore
- structuré , state-charts de Harel (états disjoints, états parallèles, macro-états)
- pliage, dépliage (exemple avec automates, exemple avec graphe de flot de contrôle d'un programme. Rappel de b a ba de programmation : nichage et séquencement.
- Expressions régulières, notation des arbres de Jackson, exemple du processus Livre, modélisation en parallèle en termes de processus et en termes ensemblistes (B ou relationnel n-aire) , vérif de cohérence entre les deux modélisations
- Le théorème de Kleene. Avant de venir en cours vous deviez lire l'histoire du concept d'automate dans le poly des sujets de TD
- Rappel : voir algo de Yamada de passage d'un automate à une expression régulière. Le cours de maths est à utiliser, réutiliser.

vendredi 25 janvier 2008

Les deux premiers cours de ce jour

J'ai traité ce que j'avais annoncé ici.
Pour assister au prochain cours, vous devrez me remettre en entrant dans l'amphi :
- le dépliage des deux automates de Harel fournis au tableau
- l'expression régulière ou l'automate pour l'American Film Star

Comme annoncé, je ne mettrai pas cette année sur ce bloc-notes les photos des tableaux noirs de mon cours.
Consultez les messages de l'an dernier.

Et les chapitres du poly de spec1 qui traitent de :

- B événementiel
- automates

jeudi 24 janvier 2008

La vie des véhicules à moteur

Faire le diagramme états-transitions étiqueté, avec transitions gardées, pour spécifier :

- l'ancien système d'identification des véhicules
- le nouveau système d'identification des véhicules
- proposez une mesure de la complexité d'un système, mesure qui utilisera les automates
- évaluez les deux systèmes
- y-a-t-il simplification ?

Ensuite proposez votre travail à Monsieur Attali et à sa commission, ou directement à Monsieur Sarkozy.
Ça fait 40 ans que chaque gouvernement français nous sort cette scie "simplification administrative" ...

mercredi 23 janvier 2008

Module Spec2, 2007-2008

Les deux premiers cours auront lieu vendredi matin prochain.

Vous devez avoir lu AVANT de venir en cours, l'introduction du poly des sujets de TD sur l''histoire du concept d'automate.
En début de cours, j'attends vos questions. Le mieux, me les adresser via les messages de ce bloc-notes ainsi tout le monde sera au courant.

Je vais traiter :

- La prise en compte des états d'évolution dans une modélisation relationnelle n-aire "à la Codd"
- Les différents types d'automates
- simple
- déterministe/indéterministe
- avec sorties : de Mealy, de Moore
- avec gardes
- structurées : automates de Harel
- j'en donnerai une sémantique en utilisant B (Eh oui, il faut casser le découpage en modules, désastreux !)

Tout sera illustré par des exemples. Ce ne sera pas un cours de maths pour l'info.

Vous pouvez trouver les photos du tableau du cours de l'an dernier sur ce même bloc-notes.

Récupérer les dossiers de TD ce jour à mon bureau via les représentants de groupes.

P.S. les intervenants en TD seront informés comme vous via ce blog.

mercredi 27 juin 2007

Corrigé des questions du PT 2007

Corrigé

1)
Il existe des langages de programmation
sans variables.

1.1) citez-en un (ou le nom d'un type
de langage entrant dans cette

catégorie)
Langages fonctionnels, exemple : Caml
1.2) quels en sont les concepts essentiels ?
fonctions, composition de fonctions,
application de fonctions


2)
Il existe des langages de spécification
sans variables.

21) B est-il sans variables ?
non.
Il existe des langages de spécification
qui sont fondamentalement sans

variables, même s'ils sont parfois mixtes
(i.e. utilisent des

variables).
2.2) Citez celui que vous avez utilisé à
l'IUT

FSP avec l'atelier LTSA
2.3) Qu'est-ce qu'un état défini en termes
des concepts de ce langage.

Donnez un exemple illustratif.
Un état est un comportement possible.
Exemple de la lampe :
ETEINTE = (tirage -> ALLUMEE),
ALLUMEE = (tirage --> ETEINTE).
Les états sont ETEINTE et ALLUMEE.

3) Prenez l'exemple de la lampe que
l'on allume en tirant une ficelle et

que l'on éteint en retirant la ficelle
pour illustrer les concepts :

3.1) d'événement
ce qui entraîne un changement d'état.
tirage de la ficelle

3.2) d'état
un comportement possible. Ici dans
l'état ETEINTE, on ne peut que tirer

sur la ficelle. Idem d'ailleurs pour
l'état ALLUMEE.

3.3) utilisez cet exemple que vous
spécifierez en B classique et en B

événementiel (Invariant et les
opérations allumer et éteindre) et en FSP

pour illustrer vos réponses à la question 2.
MACHINE
lampeClassique
SETS
ETAT = {allumee, eteinte}
VARIABLES
etatLampe
INVARIANT
etatLampe : ETAT
INITIALISATION
etatLampe := eteinte
OPERATIONS
allumer =
etatLampe := allumee;
eteindre =
etatLampe := eteinte
END

MACHINE
lampeEvénementiel
SETS
ETAT = {allumee, eteinte}
VARIABLES
etatLampe
INVARIANT
etatLampe : ETAT
INITIALISATION

etatLampe := eteinte
OPERATIONS
allumer =
SELECT etatLampe = eteinte THEN
etatLampe := allumee
END;
eteindre =
SELECT etatLampe = allumee THEN
etatLampe := eteinte
END
END

FSP

ETEINTE = (tirage -> ALLUMEE),
ALLUMEE = (tirage --> ETEINTE).

ou sans expliciter les états :
LAMPE = (tirage -> LAMPE).


3.4) Fournir le diagramme de transition
d'état étiqueté du comportement

de la lampe.
Deux ronds étiquetés l'un par allumée
et l'autre par éteinte.
Des flèches entre les ronds :
- une de éteinte vers allumée
- une de allumée vers éteinte
-selon l'état initial choisi,
une flèche pointant sur un des
ronds et n'ayant pas
de rond au départ de la flèche.
Flèche étiquetées chacune par tirer

4) Soit le texte suivant :
(Il s'agit du percement du tunnel
sous le Mont-Blanc) " [...] C'est

pourquoi, à cette époque, on avait
envisagé que sur les 12 600 mètres de

longueur totale du tunnel, les Italiens
perceraient 6 750 mètres de

galerie et les Français 5 850 mètres,
afin que la rencontre s'effectue

au
même moment." (Article paru dans
L'Economie, n° 826, 14 juin 1962).

4.1) Vos remarques pertinentes
Se rencontrer en même temps est un pléonasme !
Tant que l'autre n'est

pas au rendez-vous, la rencontre n'a pas
lieu (la communication) !

4.2) Utilisez-le pour illustrer le type
de communication qui est utilisé

en FSP (LTSA) et en CCS
C'est le rendez-vous qui est utilisé en FSP.
La communication s'y fait

lorsqu'on trouve le même nom d'événement
dans la spécification de deux

processus.

4.3) Quel est le nom donné à ce type
de communication ?

communication par rendez-vous (synchronisme)
4.4) Donnez un exemple d'un système
ayant un verrou fatal (spécifiez en

FSP)

Exemple de système avec verrou fatal :
P1 = (a -> b -> P1).
P2 = (b -> a -> P2).
||SYS = (P1 || P2).





Commentaires en vrac :
Mes questions portaient sur des choses élémentaires :
- grands types de langages de programmation (y voir un peu clair en find de 1ere année)
- mathématiques (composition de fonctions, application de fonctions)
- état, événement
- communication par rendez-vous
- verrou fatal
Il s'agissait d'illustrer en partant d'un exemple fourni.
Le corrigé vous est fourni.
==========================================


J'ai lu des phrases recopiées (j'espère qu'elles ont été mal recopiées) je ne sais où et particulièrement fumeuses.
Vous disposiez des polycopiés et sinon des cours rédigés par des enseignants compétents. Alors n'allez pas chercher ce qui est très mauvais !

Voici des textes (je n'ai pas corrigé l'orthographe) peu utiles car trop fumeux :

"le type de programmation fonctionnelle consiste en une suite de fonction"
"les états sont tous les états ..."


Il semble que beaucoup ont des difficultés de lecture du français.
A la question "qu'est ce qu'un état défini en termes des concepts de ce langage ? " (le langage est celui que l'étudiant a énoncé comme réponse à la question précédente)
j'ai lu plusieurs fois :

"un état défini est un état ...."
et bien rarement une définition exprimée avec les concepts de ce langage.

Si on a choisi FSP ou CCS, un état est défini en termes des conceps de FSP (à savoir "actions" ou "événements") comme étant la suite d'actions possible quand on est dans cet état.

Cela a été répété et illustré maintes fois, en particulier quand j'ai fait le graphe de transition d'états où je décrivais justement chaque état par une "expression d'agents" (une suite d'actions).

J'ai la preuve ! voir le présent blog spec2 !

J'ai trouvé aussi pas mal de contradictions :

"B est un langage de spécification avec variables.
Un exemple de langage de spécification sans variables est B"

L'orthographe est trop souvent du n'importe quoi. Svp apprenez le minimum d'orthographe française. C'est utile pour pouvoir spécifier en français.

J'ai eu des remarques étonnantes en termes économiques en ce qui concerne le tunnel sous le Mont-Blanc. On m'a parlé de vitesse, de rentabilité, d'efficacité. Il serait bon d'étudier les concepts élémentaires d'économie.

Je rappelle que je demandais d'utiliser le texte pour illustrer un type de communication (et je précisais même "qui est utilisé en FSP et en CCS". Ce faisant je donnais une réponse à une précédente question. Un effet de bord !)

Etonnant : les événements "tirer la ficelle" et "retirer la ficelle" et pourquoi pas "retirer retirer retirer" ?
l'événement en FSP ne se définit pas en termes d'autres événements. L'ensemble des événements est un ensemble d'éléments atomiques.

LAMPE = (tirer -> LAMPE).

ou si on veut nommer les états

ETEINTE = (tirer -> ALLUMEE),
ALLUMEE = (tirer -> ETEINTE).

si on considère deux autres événements : { allumer, éteindre}

ETEINTE = (tirer -> allumer -> ALLUMEE),
ALLUMEE = (tirer -> eteindre -> ETEINTE).

Sans référence à une théorie, il est difficile d'écrire des choses cohérentes. Merci R. Milner, T. Hoare !

lundi 18 juin 2007

Les questions de spec pour le PT

Questions

1)
Il existe des langages de programmation
sans variables.
1.1) citez-en un ou le nom d'un type de
langage entrant dans cette
catégorie)
1.2) quels en sont les concepts essentiels ?

2)
Il existe des langages de spécification
sans variables.
21) B est-il sans variables ?
Il existe des langages de spécification
qui sont fondamentalement sans
variables, même s'ils sont parfois mixtes
(i.e. utilisent des variables).
2.2) Citez celui que vous avez utilisé à l'IUT
2.3) Qu'est-ce qu'un état défini en termes
des concepts de ce langage.
Donnez un exemple illustratif.


3) Prenez l'exemple de la lampe que l'on
allume en tirant une ficelle et
que l'on éteint en retirant la ficelle
pour illustrer les concepts :
3.1) d'événement
3.2) d'état
3.3) de contrainte sur un état
3.4) utilisez cet exemple que vous
spécifierez en B classique et en B
événementiel (Invariant et une opération
principale) et en FSP pour
illustrer vos réponses à la question 2.


4) Soit le texte suivant :
(Il s'agit du percement du tunnel
sous le Mont-Blanc) " [...] C'est
pourquoi, à cette époque, on avait
envisagé que sur les 12 600 mètres de
longueur totale du tunnel, les
Italiens perceraient 6 750 mètres de
galerie et les Français 5 850 mètres,
afin que la rencontre s'effectue au
même moment." (Article paru dans
L'Economie, n° 826, 14 juin 1962).

4.1) Votre remarque pertinente sur
ce texte
4.2) Utilisez ce texte pour illustrer
le type de communication qui est
utilisé
en FSP (LTSA) et en CCS.
4.3) Quel est le nom donné à ce
type de communication ?
4.4) Donnez un exemple d'un système
ayant un verrou fatal (spécifiez en FSP)


Le corrigé et les commentaires sur
les copies seront publiés sur ce
bloc-notes sous peu.

dimanche 17 juin 2007

Ce n'est pas ...


"Les obstacles épistémologiques

  • 1945-1955 : Calculer n'est pas compter
  • 1955-1965 : Effectuer n'est pas expliciter
  • 1965-1975 : Connaître n'est pas comprendre
  • 1975-1985 : Penser n'est pas verbaliser
  • 1985-1994 : Standardiser n'est pas normaliser(1)"
Emmanuel Saint-James, mai 1993 in 3ème colloque Histoire de l'Informatique

(1) norme se traduit par standard en anglais. AFNOR en France, ANSI aux USA. Mais beaucoup de Français font la différence entre standardiser et normaliser. Si nous avons bien compris, ils utilisent "standard" comme dans l'expression "standard de fait" et "norme" dans le sens légal.

S'applique très bien à l'enseignement. Mais c'est bien loin des tendances actuelles dans notre pays.

jeudi 10 mai 2007

Les notes du DS de Spec2

Sont affichées. Le barême a été appliqué.
Le corrigé ... voir les exemples traités en cours (photos sur ce blog !) et annoncés à l'avance.