Vous êtes sur la page 1sur 43

'LJLWDOO\VLJQHGE\IDWHQ

IDWHQ
'1FQ IDWHQJQ IDWHQF 7XQLVLDO 71R ,67,&RX ,67,&H EHOIDWHQ#JPDLOFRP
5HDVRQ,DPWKHDXWKRURIWKLVGRFXPHQW
/RFDWLRQ
'DWH

Chapitre 2: Cycle de développement des


applications embarquées

1 Faten Bellakhdhar 19/10/2019


Cycle de développement des applications
informatiques

 Le cycle de développement des applications informatiques suit les


trois étapes classiques que sont la spécification, la conception et la
programmation.

 L’analyse des besoins permet d’écrire le cahier des charges de


l’application.

 À partir de ce cahier des charges, le déroulement des trois étapes


conduit successivement aux descriptions suivantes de l’application :

2 Faten Bellakhdhar 19/10/2019


Cycle de développement des applications
informatiques

3 Faten Bellakhdhar 19/10/2019


Cycle de développement des applications
informatiques

 Spécification globale : description de « ce que l’on a à faire » ou le «


quoi », c’est-à-dire une mise en forme plus ou moins formelle du «
cahier des charges ».

 Conceptions préliminaire et détaillée : description du « comment »,


c’est-à-dire une modélisation de l’architecture logicielle de
l’application (modules, tâches, objets…).

 Programmation : traduction dans un langage exécutable de


l’architecture logicielle de l’application décrite précédemment.

A chaque étape, il est primordial de vérifier la cohérence de la


description ou de la traduction réalisée à partir de l’étape précédente.
Ce travail concerne la validation.
4 Faten Bellakhdhar 19/10/2019
Cycle de développement des applications
informatiques

 Cycle de développement en « V »
 Une présentation généralement plus adaptée est celle du cycle en « V
»

5 Faten Bellakhdhar 19/10/2019


Cycle de développement des applications
informatiques

 Cycle de développement en « V »
Cette formalisation méthodologique du développement des
applications informatiques a pour principaux objectifs :
 Eviter les fautes logicielles,
 Accroître la maintenabilité,
 faciliter l’évolutivité,
…

À chaque étape ou ensemble d’étapes correspond une méthode


qui est généralement supportée par un outil informatique pour
aider à sa mise en œuvre plus ou moins automatisée.

6 Faten Bellakhdhar 19/10/2019


Cycle de développement des applications
informatiques
 Il existe de nombreuses méthodes appliquées au développement
logiciel des applications temps réel de procédé.

Méthodes fonctionnelles et structurées, dites aussi à flots de


données :
SART (Structured Analysis Real Time)
DARTS (Design Approach for Real-Time Systems)
Méthodes basées sur des modèles de machines à états
Réseaux de Petri
GRAFCET
Méthodes orientée objets
UML (Unified Modeling Language)
HOOD (Hiearchical Object Oriented Design)
7 Faten Bellakhdhar 19/10/2019
Cycle de développement des applications
informatiques

8 Faten Bellakhdhar 19/10/2019


Spécification SA-RT
La syntaxe graphique complète de SA-RT permettant
d’élaborer les différents diagrammes de la méthode.
Cette syntaxe graphique très simple peut être scindée
en deux parties : la syntaxe graphique afférente à
l’aspect fonctionnel et la syntaxe dédiée à l’aspect
contrôle ou événementiel.
La spécification d'un STR consiste en la modélisation
de ses aspects :
 Fonctionnel
 Événementiel

9 Faten Bellakhdhar 19/10/2019


Spécification SA-RT: Fonctionnel

Les fonctionnalités que le système doit satisfaire,

Les informations qu'il doit traiter au niveau logique.

Cette étape ne doit pas tenir compte de la manière


de réalisation.

QUOI FAIRE?

10 Faten Bellakhdhar 19/10/2019


Spécification SA-RT: Fonctionnel
Le modèle fonctionnel prend en considération:

Les données porteuses de traitement

o leur provenance
o leur destination
o leur stockage intermédiaire

 Les transformations qu'elles subissent

11 Faten Bellakhdhar 19/10/2019


Spécification SA-RT: Fonctionnel
La méthode SA (Structered Analysis) permet de
modéliser, de façon statique, l'activité d'un système
sous forme de flots de données circulant entre les
processus.

Un outil de modélisation de l'aspect fonctionnel d'un


système doit permettre de:
représenter le travail de transformation que le
système opère sur les données.
spécifier les processus qui transforment les
données.

12 Faten Bellakhdhar 19/10/2019


Spécification SA-RT: Fonctionnel
Diagramme de contexte

Exemple: (Exploitation de mesures acquises)


13 Faten Bellakhdhar 19/10/2019
Spécification SA-RT: Fonctionnel
Diagramme Préliminaire

14 Faten Bellakhdhar 19/10/2019


Spécification SA-RT: Fonctionnel

15 Faten Bellakhdhar 19/10/2019


Aspect fonctionnel:
Flot de données:
Définition: un flot de donnée indique le chemin suivi par
une donnée qui circule entre des transformations. Il peut
être constitué d'une donnée simple, dite primitive, ou
d'un groupement de données.

Représentation: une flèche simple ou double étiquetée


avec L'identificateur de la donnée. L'identificateur de la
donnée ne doit impliquer aucun traitement, il ne
comporte que des noms et des adjectifs

16 Faten Bellakhdhar 19/10/2019


Aspect fonctionnel:

Une flèche simple = un flot de données discrets dans le temps:


Ce flot de données a un nombre de valeurs limitées, définis en
des points isolés du temps et indéfinis en dehors de ses points.
Exemple: le code d'une carte DAB n'est valable que si la carte est
insérée dans le lecteur.

Une flèche double = un flot de données continu. Ce flot de


données a des valeurs définies en tout point du temps.
Exemple: température livrée par un capteur.
17 Faten Bellakhdhar 19/10/2019
Aspect fonctionnel:
Processus
Définition: un processus est une unité d'activité réalisée
par le système, qui change un ou plusieurs flots de données
entrants en un ou plusieurs flots de données sortants. Un
processus accepte, stocke et/ou produit des flots de
données.
Présentation: un cercle entourant L'identificateur du
processus et un numéro de référence. L'identificateur du
processus décrit la transformation opérée à l'aide d'un
verbe d'action à l'infinitif, suivi, éventuellement, d'un
complément d'objet direct, qui concerne la donnée sur
laquelle porte la transformation. La référence numérique
traduit la place du processus dans une décomposition
hiérarchique.
18 Faten Bellakhdhar 19/10/2019
Aspect fonctionnel:

19 Faten Bellakhdhar 19/10/2019


Aspect fonctionnel:
Stockage de données:
Définition : un stockage de donnée est un regroupement
de données, ou une donnée primitive, maintenu disponible
et qui peut être utilisé par tout processus. Son contenu n'est
pas changé par un processus qui y lit, il n'est modifié que
par un processus qui y écrit.
Représentation: deux lignes parallèles encadrant
l'identificateur de la donnée stockée. Cet identificateur doit
être composé de la même manière que celui d'un flot.

20 Faten Bellakhdhar 19/10/2019


Aspect fonctionnel:
Stockage de données:
Pour des besoins de clarté graphique, un stockage de
données peut être visualisé plusieurs fois sur un
diagramme flot de données en notant cette duplication
par une « * ».
Il est important de noter que l’utilisation de l’élément «
stockage de données » peut correspondre à deux cas :
– mémorisation ou représentation des constantes
du système ;
– mémorisation de valeurs de données partagées
entre deux ou plusieurs processus
désynchronisés (consommation et production
des données à des instants ou des rythmes
différents).
21 Faten Bellakhdhar 19/10/2019
Aspect fonctionnel:
Bord de modèle
Définition: un bord du modèle représente une entité située
dans l'environnement externe au système, qui constitue la
source ou la destination des flots de données échangés
entre le système et son environnement. Il peut être un
périphérique, une partie opérative, une personne ou un
autre système.
Représentation: un rectangle entourant L'identificateur du
bord. L'identificateur d'un bord est composé de noms qui
indiquent le rôle qu'il joue ou la place qu'il tient, par
rapport au système.

22 Faten Bellakhdhar 19/10/2019


Aspect fonctionnel:
Les règles de formation et d'interprétation d'un DFD

de Vers Processus Stockage Bord

Processus * * *

Stockage *

Bord *

23 Faten Bellakhdhar 19/10/2019


Aspect fonctionnel:
La hiérarchisation du modèle fonctionnel
Pour réduire la complexité d'un système en phase de
modélisation on opte à en hiérarchiser le modèle, de façon
descendante, par niveaux de détail croissant, et de
complexité suffisamment limité pour pouvoir être
facilement assimilable.
Diagramme de contexte
Le diagramme de contexte est le sommet de la hiérarchie.
C'est un diagramme très abstrait qui représente le système
à modéliser. Il ne contient qu'un processus dont le nom
traduit la fonction d'usage du système. Il est le seul
diagramme dans lequel sont représentées les interfaces
entre le système et l'environnement (les bords).

24 Faten Bellakhdhar 19/10/2019


Aspect fonctionnel:
Diagramme de contexte

25 Faten Bellakhdhar 19/10/2019


Aspect fonctionnel:
Niveaux de décomposition:
Un DFD de premier niveau, appelé diagramme
préliminaire, fait la décomposition des systèmes qui
correspondent aux fonctions principales du système et
à leurs interfaces.
Chaque sous système est considéré à son tour comme
système et il est décomposé itérativement en sous
systèmes.
La décomposition d'un processus s'accompagne de
celle du contexte qui lui est associé, c'est-à-dire des
flots des données qui y entrent et qui en sortent.

26 Faten Bellakhdhar 19/10/2019


Aspect fonctionnel:
Les règles de formation et d'interprétation d'un DFD
Repérage des niveaux et des processus: Chaque niveau
porte le nom et le numéro du processus parent qu'il
décompose. Chaque processus du DFD d'un niveau,
possède une référence numérique qui indique sa place
dans la hiérarchie.
Processus primitif: Un processus est dit primitif s'il
n'est plus décomposable.

27 Faten Bellakhdhar 19/10/2019


Aspect fonctionnel:

28 Faten Bellakhdhar 19/10/2019


Aspect Événementiel:
Digrammes de flots de contrôle
Dans les diagrammes flot de données, le déclenchement
de l’exécution des processus de transformation de
données peut être lié au rythme d’apparition des
données entrantes (diagramme piloté par les données :
data-driven).
Mais, dans le cas de la spécification des applications
temps réel, il est préférable d’avoir un contrôle de ces
transformations de données piloté par des conditions
externes comme l’occurrence d’événements (event-
driven).
Cette vue dynamique du modèle impose la mise en place
de la partie contrôle : processus de contrôle et flot de
contrôle.

29 Faten Bellakhdhar 19/10/2019


Digrammes de flots de contrôle
Le Processus de contrôle représente la logique du
pilotage des processus fonctionnels.
Il génère l’ensemble des événements qui vont activer
ou désactiver les processus fonctionnels.
En retour, les processus fonctionnels fournissent au
processus de contrôle tous les événements nécessaires
aux prises de décision. Le processus de contrôle ne
peut en aucun cas gérer des données.
Le Processus de contrôle est représenté par un cercle
en pointillé avec une étiquette ou label explicite formé
de: Étiquette_Processus_Contrôle verbe (+ un ou
plusieurs compléments) + numéro

30 Faten Bellakhdhar 19/10/2019


Digrammes de flots de contrôle
Le Flot de Contrôle transporte les événements ou
informations qui conditionnent directement ou
indirectement l’exécution des processus de
transformations de données. Le flot de contrôle est
représenté par un arc orienté pointillé avec une
étiquette ou label explicite formé

31 Faten Bellakhdhar 19/10/2019


Digrammes de flots de contrôle
Les événements, fournis par le processus de contrôle, sont
généralement liés à l’activation ou à la désactivation des
processus fonctionnels. Aussi, ces événements spécifiques
ont été formalisés et prédéfinis :
– E pour Enable (activation) ;
– D pour Disable (désactivation) ;
– T pour Trigger (déclenchement).
Les deux premiers événements sont utilisés ensemble «E/D
» pour piloter un processus fonctionnel de type « boucle
sans fin » ou périodique, c’est-à-dire que le processus de
contrôle doit lancer l’exécution de ce processus avec
l’événement « E» et ensuite peut l’arrêter avec l’événement
«D».
32 Faten Bellakhdhar 19/10/2019
Digrammes de flots de contrôle
L’événement «T» est utilisé pour activer un processus
fonctionnel de type « début-fin » ou sporadique, c’est-
à-dire que le processus de contrôle doit lancer
l’exécution de ce processus avec l’événement «T» et
ensuite le processus s’arrête à la fin de son exécution
sans intervention du contrôle.

33 Faten Bellakhdhar 19/10/2019


Digrammes de flots de contrôle
Un diagramme préliminaire ne doit contenir qu’un seul
processus de contrôle. En effet, il est difficilement concevable
d’avoir plusieurs organes de contrôle commande pour une seule
application, pour des raisons de cohérence.
Un diagramme préliminaire, ou, a fortiori, un diagramme de
décomposition, peut ne pas avoir de processus de contrôle. Dans
ce cas, tous les processus fonctionnels sont supposés s’exécuter
en même temps avec pour seule règle celle des flots de données.
Un processus fonctionnel peut ne pas être connecté au processus
de contrôle. Dans ce cas, il est supposé être activé au démarrage
de l’application et ne jamais s’arrêter. Aussi, pour augmenter la
lisibilité, il est préférable de le connecter au processus de
contrôle avec un événement de type « E/D » et de l’activer
définitivement au début de l’application en utilisant l’événement
« E ».

34 Faten Bellakhdhar 19/10/2019


Diagramme état/transition
Cette spécification, représentant l’aspect comportemental ou temps réel
de l’application, peut être faite de diverses manières : diagramme état-
transition, table état transition, matrice état-transition ou
éventuellement un grafcet.
– état courant correspondant à un fonctionnement précis du
système, en particulier à un état des processus fonctionnels
(exécution ou non) ;
– événement : occurrence d’un événement émanant d’un processus
fonctionnel vers le processus de contrôle qui va provoquer le
franchissement de la transition et donc faire changer l’état du
système ;
– action : occurrence d’un événement émanant du processus de
contrôle vers un ou plusieurs processus fonctionnels pour les
activer (« E » ou « T ») ou les désactiver (« D »). Ces actions
caractérisent l’effet du franchissement de la transition ;
– état suivant correspondant au fonctionnement après les actions
faites par le processus de contrôle en direction des processus
fonctionnels.

35 Faten Bellakhdhar 19/10/2019


Diagramme état/transition
Les actions du processus de
contrôle sur les processus
Fonctionnels sont notées
par « < E ou D ou T > + numéro
ou nom du processus fonctionnel ».
Il peut y avoir plusieurs
actions de ce type associées
à une seule
transition.

36 Faten Bellakhdhar 19/10/2019


Présentation d’un exemple simple
d’application de contrôle-commande
Considérons un système de freinage automobile qui est constitué
d’une part d’un ensemble classique composé d’une pédale de frein
(demande de freinage) et d’un frein (actionneur de freinage) et
d’autre part d’un système ABS (Anti-blocking Brake System).
Un capteur de glissement de roues est associé à ce système ABS.
Pour simplifier, le fonctionnement de l’ABS est basé sur un arrêt du
freinage dès qu’un glissement est détecté sur les roues, et cela même
si la demande du conducteur est toujours effective.
Le conducteur a la possibilité d’activer ou non ce système ABS à
l’aide d’un bouton spécifique (bouton à deux positions stables :
interrupteur).
Un voyant permet de lui indiquer l’activation du système ABS. En
revanche, il n’est pas possible de désactiver le système ABS en cours
de freinage, c’est-à-dire pendant l’appui sur la pédale de frein part
d’un système ABS (Anti-blocking Brake System).

37 Faten Bellakhdhar 19/10/2019


Présentation d’un exemple simple
d’application de contrôle-commande
Un seul processus fonctionnel, numéroté « 0 ». Dans l’exemple
simple d’un système de freinage automobile, le diagramme de
contexte est constitué du processus fonctionnel « Contrôler
système freinage 0 » et de cinq bords de modèles:
– terminaison « Pédale de frein » fournissant la donnée «
Demande_freinage » ;
– terminaison « Bouton d’activation de l’ABS » fournissant la
donnée « Activation_ABS » ;
– terminaison « Capteur de glissement » fournissant la donnée
« Glissement_roue » ;
– terminaison « Système de freinage » consommant la donnée «
Commande_freinage » ;
– terminaison « Voyant ABS » consommant la donnée «
Affichage_ABS ».
38 Faten Bellakhdhar 19/10/2019
Diagramme de contexte de l’application « système de
freinage automobile

39 Faten Bellakhdhar 19/10/2019


Diagramme flots de données de l’application
« système de freinage automobile »

40 Faten Bellakhdhar 19/10/2019


Diagramme flots de données de l’application
« système de freinage automobile
Dans le cas de l’exemple du système de freinage
automobile, le diagramme préliminaire va être modifié
pour intégrer un processus de contrôle. En particulier,
les deux flots de données « Etat_glissement » et «
Etat_bouton_ABS » de type booléen deviennent des
événements envoyés respectivement par les processus
fonctionnels « Détecter glissement roue » et « Lire
boutons ABS ».

41 Faten Bellakhdhar 19/10/2019


42 Faten Bellakhdhar 19/10/2019
Diagramme état/transition de l’application «
système de freinage automobile »

43 Faten Bellakhdhar 19/10/2019