Dan Garlasu, dgarlasu@yahoo.

com

1
 Agenda
1. Travailler avec des objets de données persistants
i. Fonctions de base de données
ii. Utilisation des fonctions de base de données
2. Paradigme fonctionnel : résumé
i. Principales caractéristiques du paradigme fonctionnel
ii. Avantages du paradigme
iii. L'ingénierie logicielle et le Paradigme de programmation fonctionnelle

2
 Du point de vue de l'ingénierie logicielle, un langage sans prise en charge de la
persistance des objets de données, peut sembler complètement impraticable.
 Le paradigme fonctionnel prend en charge les objets de données persistants
en tant que composant spécial - les données fonctionnelles.
 Le modèle de données fonctionnelles définit des fonctions associées aux
bases de données par des:
◦ Objets de données persistants,
◦ des attributs,
◦ des relations
 Les fonctions associées aux bases de données peuvent être intégrées de
manière transparente aux fonctions ordinaires mentionnées ci-dessus à l'aide
d'opérateurs de construction

La persistance en informatique fait référence à la caractéristique de l'état qui survit

au processus qui l'a créé.
(http://en.wikipedia.org/wiki/Persistence_(computer_science))

Un objet persistant continue d'exister et conserve ses données au-delà de la durée

du processus qui l’a crée. En revanche, un objet transitoire n'existe que dans la
mémoire du processus qui l’a crée; lorsque ce processus se termine, l'objet
transitoire cesse d'exister.
(http://devnet.objectivity.com/objects_faq)

3
 Les objets de données sont appelés entités de base de données ou
simplement entités dans la terminologie du modèle de données fonctionnel.
 Toutes les entités doivent être déclarées en tant que fonctions spéciales
dépourvues de paramètres.
 Par exemple, le schéma de base de données traitant les trois Entités
suivants: Customer, Product et Transaction où chaque transaction décrit une
expédition d'un produit à un client, peut être défini comme suit:
◦ CUSTOMER( )  ENTITY
◦ PRODUCT( )  ENTITY
◦ TRANSACTION( )  ENTITY
Notez que deux ou plusieurs entités différentes au sein d'une base de
données fonctionnelle peuvent avoir des valeurs dupliquées de tous les
éléments de données (des attributs).

4
  La clé interne (IK – Internal Key) est conceptuellement un
élément de données dont la valeur est automatiquement
associée à chaque entité stockée dans la base de données.
 Nous pouvons le considérer comme un identifiant interne unique
utilisé dans une base de données pour distinguer une entité
d'une autre.
 Chaque entité se voit attribuer une valeur de clé interne
lorsqu'elle est stockée dans la base de données pour la première
fois.
 Une entité conserve une valeur de la clé interne (même si l'entité
est modifiée) jusqu'à ce que l'entité soit définitivement supprimée
de la base de données.

Note: La clé interne (IK – Internal Key) analogue a Primary Key

5
 Ainsi, nous pouvons considérer la fonction
<entity name>( )  ENTITY
 comme une fonction qui produit une valeur particulière de la
clé interne pour chaque entité existante.
 Par exemple, la fonction
CUSTOMER( )  ENTITY
pourrait ressembler à ceci:
Entity Internal key
#1, Smith, . . . $C1
#2, Hill, . . . $C2
#8, Johns $C3

6
 Par analogie, tous les attributs d'une entité particulière
doivent également être définis sous forme de fonctions.
 Par exemple, si l'entité "CLIENT" est décrite avec C#(numéro
de client), CNAME (nom du client), CITY (ville où vit le client)
et PHONE (numéro de téléphone du client), alors ces
fonctions doivent être déclarées comme suit :

◦ C#(CUSTOMER)  integer
◦ CNAME(CUSTOMER)  string
◦ CITY(CUSTOMER)  string
◦ PHONE(CUSTOMER)  integer

7
 Une telle fonction mappe une valeur particulière de la clé
interne dans une valeur correspondante de l'attribut.
 Par exemple, les fonctions:
C#(CUSTOMER)  integer
CNAME(CUSTOMER)  string
 pourrait ressembler à ceci :

C#(CUSTOMER) integer CNAME(CUSTOMER) string

C#($C1) 1 CNAME($C1) Smith
C#($C2) 2 CNAME($C2) Hill
C#($C3) 8 CNAME($C3) Johns

8
  Normalement, un modèle d'information se compose de deux parties
principales :
◦ entités et
◦ des relations
 Les mécanismes du modèle fonctionnel de données décrits jusqu'à présent
ne suffisent pas à couvrir les relations entre entités qui sont, évidemment,
une partie très importante d'un modèle d'information. Considérez, par
exemple, les relations suivantes dans la base de données en cours de
discussion:

Le client Smith ($C1) a acheté le produit VDU ($P1), cet événement est représenté
dans la base de données par l'entité TRANSACTION avec la clé interne $T1. Le
client Hill ($C2) a également acheté le même produit (voir l'entité TRANSACTION
avec clé interne $T2). De telles relations entre entités sont décrites comme des
fonctions associées aux bases de données qui sont appliquées aux entités et
renvoient des entités en conséquence.

9
  Par exemple,
CT(TRANSACTION)  CUSTOMER
PT(TRANSACTION)  PRODUCT
 Des fonctions de ce type transforment une clé interne d'une entité
en clé interne correspondante d'une autre.
 Ainsi, pour l'exemple discuté précédemment, les fonctions sont
les suivantes:
CT(TRANSACTION) CUSTOMER PT(TRANSACTION) PRODUCT

CT($T1) $C1 PT($T1) $P1

CT($T2) $C2 PT($T2) $P1

10
 Par conséquent, le modèle de données fonctionnel définit un schéma associé à une
base de données comme un ensemble de fonctions de base de données.
 Par example:
/* Definitions of entities */
CUSTOMER( )  ENTITY
PRODUCT( )  ENTITY
TRANSACTION( )  ENTITY
/* Definition of attributes */
C#(CUSTOMER)  INTEGER
CNAME(CUSTOMER)  STRING
CITY(CUSTOMER)  STRING
PHONE(CUSTOMER)  INTEGER
P#(PRODUCT)  INTEGER
PNAME(PRODUCT)  STRING
PRICE(PRODUCT)  INTEGER
DATE(TRANSACTION) STRING
QNT (TRANSACTION)  INTEGER
TPRICE(TRANSACTION) INTEGER
/* Definition of relationships */
CT(TRANSACTION)  CUSTOMER
PT(TRANSACTION)  PRODUCT

11
  Il existe une notation graphique utile pour les schémas de
bases de données fonctionnelles. Cette notation est connue
sous le nom de diagramme de structure de données

Conformément à la notation, chaque entité (c'est-à-dire une fonction qui définit une
entité) est représentée sous la forme d'un rectangle. Le rectangle contient le nom de
l'entité. Toutes les autres fonctions sont représentées par des flèches. La flèche est
dirigée vers l'entité ou le type de données résultant; la flèche émane du symbole
d'entité qui correspond aux paramètres de la fonction.

12
 Dans le modèle de données fonctionnel, pour chaque fonction f(s)  t la
fonction inverse Inv_f(t)  s est également disponible.
 Par exemple, la fonction inverse INV_C#(integer)  CUSTOMER
◦ mappe les valeurs de l'attribut C# dans les clés internes de l'entité Customer
De manière analogue, la fonction inverse
INV_CNAME(STRING)  CUSTOMER
◦ transforme une valeur particulière de l'attribut CNAME en une clé interne
correspondante d'une entité CUSTOMER
INV_C#(integer) CUSTOMER INV_CNAME(string) CUSTOMER
INV_C#(1) $C1 INV_CNAME(Smith) $C1
INV_C#(2) $C2 INV_CNAME(Hill) $C2
INV_C#(8) $C3 INV_CNAME(Johns) $C3

13
 Il existe également des fonctions inverses qui décrivent des relations entre
entités.
 Ex: la fonction inverse INV_CT(CUSTOMER)  TRANSACTION transforme
une clé interne de l'entité CUSTOMER en une clé interne correspondante de
l'entité TRANSACTION
INV_CNAME(string) CUSTOMER

INV_CT($C1) $T1

INV_CT($C2) $T2

Le modèle de données fonctionnel prend en charge les fonctions à valeur

unique et à valeurs multiples. Toutes les fonctions discutées jusqu'à présent
sont à valeur unique car elles produisent une valeur unique comme résultat.

14
 Les fonctions à plusieurs valeurs produisent des résultats qui appartiennent à
ce que l'on appelle un type de données en bloc (bulk data type).
◦ Le seul type de données «bloc» disponible dans le modèle de données fonctionnel est
une liste (c'est-à-dire un nombre séquentiel d'éléments qui peuvent être des listes ou des
valeurs uniques à leur tour).
◦ Par conséquent, les fonctions à valeurs multiples sont représentées par des fonctions à
valeurs de liste dans le modèle de données fonctionnel.
 Par exemple, la fonction inverse
INV_PT(PRODUCT) TRANSACTION
◦ est une fonction de liste car elle produit généralement une liste de valeurs comme résultat
INV_PT($P1)  [$T1, $T2] est une liste de valeurs uniques de clés internes
 Notez qu'une fonction à valeur unique peut être appliquée à une liste (c'est-à-dire qu'une liste
de valeurs peut être utilisée comme paramètre d'une fonction à valeur unique).

15
 Par exemple,

INV_CT([$C1,$C2])  [$T1,$T2]
liste comme paramètre liste comme résultat
CNAME([$C1,$C2])  [Smith, Hill]

 Le type d'une fonction de base de données particulière donne des informations essentielles
sur la sémantique d'une base de données.
 Par exemple, si la fonction INV_C# (integer)  CUSTOMER est définie comme une fonction
à valeur unique, alors l'attribut C# peut être considéré comme une clé externe (c'est-à-dire
que les valeurs dupliquées ne sont pas autorisées).
 Par analogie, la définition de la fonction CT(TRANSACTION)  CUSTOMER comme une
fonction à valeur unique assure que chaque entité "TRANSACTION" correspond exactement
à une seule entité « CUSTOMER", et ainsi de suite.

16
 Ainsi, afin de distinguer les types de certaines fonctions,
◦ les fonctions à valeur unique sont représentées par des flèches à une pointe ()
◦ les fonctions à plusieurs valeurs sont représentées par des flèches à double pointe
()
 Si la fonction inverse n'est pas explicitement déclarée comme une fonction
à valeur unique, elle est considérée comme une fonction à valeurs
multiples (option par défaut)
 Par exemple, les fonctions INV_CNAME, INV_PT, INV_CT etc. sont à
valeurs multiples et, par conséquent, peuvent être définis comme suit:
INV_CNAME(STRING)  CUSTOMER
INV_CT(CUSTOMER)  TRANSACTION
INV_PT(PRODUCT)  TRANSACTION

17
 Ainsi, un système de base de données fonctionnelle
comprend les composants suivants
1. Fonctions de base de données
2. Etat actuel des fonctions associées à une base de données définie
comme une collection de paires

[Parameter] [Resultant Value]

18
  Les requêtes (queries) dans le modèle de données fonctionnel sont
également définies à l'aide de fonctions.
 Une telle fonction définie par l'utilisateur est appelée fonction de requête
(query) ou fonctions de manipulation de données. Dans le cas le plus
simple, les fonctions associées aux bases de données peuvent être
simplement combinées afin de créer des fonctions de requête.
 Par exemple, la requête
"Obtenir les noms des clients de Paris" peut être défini comme la fonction composite suivante:
CNAME(INV_CITY("Paris"))  string
 Supposons qu'une base de données soit définie au moyen de deux
fonctions de base de données :
CITY(CUSTOMER)  string, et CNAME(CUSTOMER)  string

String se traduit par chaîne

19
 Supposons qu'une base de données soit définie au moyen de deux
fonctions de base de données
 Supposons également que les fonctions se présentent comme suit:
CITY(CUSTOMER) string CNAME(CUSTOMER) string
CNAME ($C1) Smith
CITY ($C1) London
CITY ($C2) Paris CNAME ($C2) Hill

CITY ($C3) Graz CNAME ($C3) Johns

CITY ($C4) Paris CNAME ($C4) Maier

Dans ce cas particulier, la requête est évaluée comme suit:

INV_CITY("Paris")  [$C2,$C4]
CNAME(($C2,$C4))  ["Hill", "Maier"]
De manière analogue, la requête "Obtenir les noms des clients qui ont acheté le produit
« CPU » est définie sous la forme :
CNAME( CT( INV_PT(INV_PNAME(“CPU") ) ) )  string

20
 Supposons également que les fonctions de la base de données (c'est-
à-dire l'état actuel de la base de données) se présentent comme suit :

PNAME(CUSTOMER) string PT(TRANSACTION) PRODUCT

PT ($T1) $P1
PNAME ($P1) CPU
PT ($T2) $P2
PNAME ($P2) VDU
PT ($T3) $P1
PT ($T4) $P2

Ainsi, la fonction a valeurs multiples INV_PT renvoie les listes suivantes:

INV_PT($P1)  [$T1, $T3]
INV_PT($P2)  [$T2, $T4]

21
Si l'on prend la fonction Customer TransactionsCT :
CT(TRANSACTION) CUSTOMER
CT ($T1) $C1
CT ($T2) $C2
CT ($T3) $C3
PT ($T4) $C4

Dans ce cas, la fonction est interprétée comme suit:

1. INV_PNAME("CPU") [$P1]
2. INV_PT([$P1])  [$T1,$T3]
3. CT([$T1,$T3])  [$C1,$C3]
4. CNAME([$C1,$C3])  ["Smith", "Johns"]

22
 Les programmes fonctionnels n'utilisent pas de variables - il n'y a pas d'état. Par
conséquent, ils ne peuvent pas utiliser les assignations, puisqu'il n'y a rien à assigner.
 Il n'y a pas de séquence de commandes. La première commande ne fait aucune
différence avec la seconde puisqu'il n'y a pas d'état pour servir de médiateur entre
eux.
 Les programmes fonctionnels peuvent utiliser des fonctions de manière beaucoup
plus sophistiquée. Les fonctions peuvent être traitées exactement de la même
manière que des objets plus simples comme des entiers:
◦ ils peuvent être passés à d'autres fonctions en tant qu'arguments
◦ retourné comme résultats
◦ en général calculé avec.
 Au lieu de séquencer et de boucler, les langages fonctionnels utilisent des fonctions
récursives, c'est-à-dire fonctions définies par elles-mêmes. En revanche, la plupart
des langues traditionnelles offrent des installations médiocres dans ces domaines*.
*) Le langage C permet une manipulation limitée des fonctions via des pointeurs, mais
ne permet pas de créer dynamiquement de nouvelles fonctions. FORTRAN ne
supporte même pas du tout la récursivité.

Remarque : le langage C permet une manipulation limitée des

fonctions via des pointeurs, mais ne permet pas de créer
dynamiquement de nouvelles fonctions. FORTRAN ne supporte
même pas du tout la récursivité.

23
  Les programmes fonctionnels correspondent plus directement à des
objets mathématiques, et il est donc plus facile de raisonner dessus
 Afin de bien comprendre ce que signifient exactement les
programmes, nous pourrions souhaiter attribuer une signification
mathématique abstraite à un programme ou à une commande - c'est
le but de la sémantique dénotationnelle (décrivant toutes les
fonctionnalités trouvées dans les langages de programmation
impératifs avec une base mathématique solide)
 Les programmes fonctionnels peuvent bien se prêter à une mise en
œuvre parallèle, c'est-à-dire l'ordinateur peut automatiquement
exploiter différentes sous-expressions vers différents processeurs
http://www.csse.monash.edu.au/~lloyd/tilde/Semantics/

À première vue, un langage sans variables ni séquençage peut sembler complètement

impraticable. Cette impression ne peut être dissipée par quelques mots ici. Mais nous
espérons qu'en étudiant le matériel ci-dessus, les lecteurs auront compris comment il est
possible de faire beaucoup de programmation intéressante de manière fonctionnelle. De
nombreuses fonctionnalités des langages impératifs sont apparues par un processus
d'abstraction du matériel informatique typique, du code machine aux assembleurs, aux
macro-assembleurs, puis au FORTRAN et au-delà.
Peut-être que la bonne approche n'est pas de commencer par le matériel et de travailler
vers le haut, mais de commencer par les langages de programmation en tant que
notation abstraite pour spécifier les algorithmes, puis de descendre jusqu'au matériel
(approche axée sur l'utilisateur). En fait, cette tendance peut également être détectée
dans les langues traditionnelles.
Le programmeur n'est pas chargé de la tâche de linéariser l'évaluation des sous-
expressions et de trouver un stockage temporaire pour les résultats intermédiaires. Cela
suggère que l'idée de développer des langages de programmation assez différents des
impératifs traditionnels est certainement défendable. Cependant, pour souligner que
nous ne proposons pas simplement le changement pour le plaisir du changement, nous
devrions dire quelques mots sur les raisons pour lesquelles nous pourrions préférer les
programmes fonctionnels aux programmes impératifs.

24
 Réutilisabilité: toute personne ayant besoin d'une fonctionnalité
particulière peut utiliser une fonction appropriée, sans avoir à
coder l'algorithme à partir de zéro.
 Spécialisation: une personne peut se concentrer sur l'écriture
d'une meilleure fonction possible pour une tâche particulière
tandis que d'autres s'occupent d'autres domaines.
 Évolutivité: si un programmeur propose une meilleure façon
d'implémenter une fonction, il remplace simplement le code dans
la fonction.
 De toute évidence, le paradigme est le mieux adapté au modèle
de prototypage rapide du développement logiciel.

25
 Le prototypage repose sur l'idée de développer une première implémentation pour les retours des
utilisateurs, puis d'affiner ce prototype à travers de nombreuses versions jusqu'à ce qu'un système
satisfaisant émerge.

• Programmation exploratoire - travaillez avec l'utilisateur pour explorer ses besoins et fournir un
système final.
• Prototypage jetable - L'objectif est de comprendre les exigences des utilisateurs et de développer
une meilleure définition des exigences pour le système

Le prototypage, aussi appelé développement évolutif, ou RAD (Rapid Application Development) vise à
améliorer la précision de la perception par le concepteur des besoins de l'utilisateur. Le prototypage
repose sur l'idée de développer une première implémentation pour les retours des utilisateurs, puis
d'affiner ce prototype à travers de nombreuses versions jusqu'à ce qu'un système satisfaisant émerge.
Les activités de spécification, de développement et de validation sont menées en parallèle avec un
retour d'expérience rapide sur l'ensemble des activités. Généralement, le prototypage se caractérise
par l'utilisation de langages de très haut niveau, qui ne seront probablement pas utilisés dans
l'implémentation logicielle finale mais qui permettent un développement rapide, et le développement
d'un système avec moins de fonctionnalités par rapport aux attributs de qualité tels que la robustesse,
vitesse, etc... Le prototypage permet de clarifier les besoins des utilisateurs grâce, notamment, au
développement précoce de l'interface utilisateur. L'utilisateur peut alors essayer le système, même s'il
s'agit d'un (sous-)système de ce qui sera le produit final. Cela permet à l'utilisateur de fournir des
commentaires avant qu'un investissement important n'ait été fait dans le développement du mauvais
système.
Des expériences de prototypage ont montré que cette approche prenait 40 % de temps en moins et
entraînait 45 % de code en moins ; cependant, il produisait un code moins robuste et donc plus difficile
à maintenir. La documentation était souvent sacrifiée ou incomplète. Les attentes de calendrier des
utilisateurs et des gestionnaires avaient tendance à être irréalistes, en particulier en ce qui concerne les
prototypes jetables.

Exemple : utilisez Oracle APEX pour le développement rapide d'applications afin de rendre vos données
Oracle rapidement et facilement disponibles via une application Web. • Créez de puissantes
applications Web multipages fonctionnelles en quelques minutes • Utilisez des rapports "interactifs"
avancés prêts à l'emploi • Intégrez les fonctionnalités javascript et AJAX avec des actions dynamiques
construites par pointer-cliquer • Créez facilement des graphiques et des diagrammes avec drill-to -
fonctionnalités détaillées • Comprendre les multiples outils en un d'APEX, y compris le développement
complet SQL/PLSQL et les capacités d'administration.

26