Chap 2 Cycle Vie SE

Conception et programmation des
systèmes embarqués
Pr.Youssefi
Département GEGM
FST-Settat
Chapitre II: Cycle de vie d’un système embarqué Pr.Youssefi FST Settat
Chapitre II:
Cycle de vie d’un système embarqué
Chapitre II: Cycle de vie d’un système embarqué Pr.Youssefi FST Settat 2
Plan de chapitre
I- Processus de développement d’un SE

II- Cycle de vie d’un SE
1- Cycle de vie en cascade
2- Cycle de vie en V
3- Cycle de vie en W
III- Validation, vérification et tests (VVT)
1- Définitions
2- Nature de l’information utilisée pour les tests
3- Cycle de vie et acteurs VVT
4- Tests de validation
Pourquoi un processus de conception des SE?
 Le développement et l’évolution d’un SE doit être vu comme un

processus.
Processus :
 Ensemble d’activités coordonnées et régulées, en partie ordonnées,
dont le but est de créer un produit.
 Un processus décrit 2 choses importantes :
• Les activités (étapes) (QUOI ?)
• L’enchainement des activités (QUAND?)
Pourquoi un processus de conception des SE?
 Principe: « Diviser pour mieux régner. »

 Généralement, un système embarqué à développer est un problème
très complexe à résoudre.
 Pour appréhender la complexité de développement, il faut arriver :
• à rendre les choses simples.
• séparer les problèmes afin de les résoudre de manière presque
indépendante.
Phases d’un processus de développement d’un SE
Chaque phase est décrites en termes de :

• Entrées: matière première (besoins client)
• Sorties: résultat (livrable)
• Intervenants et rôles (qui ?)
• Description de l’activité (quoi - quel est le problème à traiter ?)
• Standards, méthodes, « best practices » à appliquer, … (comment?)
Les phases courantes et problèmes traités :

Spécifier Valider
Qu’est-ce que le SE doit faire? Le SE fait-il ce qu’il doit faire?
Comment s’assurer qu’il le fait? Développe t on le bon logiciel?
Comment s’assurer qu’on développe le bon SE?
Concevoir Intégrer
Comment organiser le SE pour qu’il fasse ce Le SE est-il organisé et construit de
qu’il doit faire? manière à faire ce qu’il doit faire?
Quelles choix techniques faut-il faire pour que le
SE fasse ce qu’il doit faire?
Comment s’assurer que le SE est organisé et
construit de manière à faire ce qu’il doit faire?
Implémenter: Coder/Réaliser Tester unitairement
Comment traduit-on cette organisation en code Le code source est-il bien écrit?
source et hardware?
1- Etude préalable de faisabilité

 Faisabilité technique: Contraintes techniques et alternative.
Exemple; Robot soldat, serveur café.
 Faisabilité financière: Estimation de cout (approximative),
l’estimation plus précise ne peut pas être élaborée avant les phases
spécification et conception.
2- Spécifications (Quoi?)
Phase Spécification
Description • Décrire ce que doit faire le système (comportement en boite
noire).
• Décrire comment vérifier en boite-noire que le système fait
bien ce qui est exigé.
Entrées • Exigences client (fonctionnelles et non fonctionnelles)
• Désir, besoins
Sorties Livrables:
• Cahier des spécifications détaillées
• Procédures de validation
Intervenants Maitre d’ouvrage (client), Maitre d’œuvre
Standards, méthodes, Nombreux formalismes: Méthode SART, UML, SysML,…
best practices,…
2- Spécifications (Quoi?)
Spécification – bonnes pratiques
• Les livrables de la phase spéc, constituent un contrat explicite
(accord) entre le client et les architectes (maitre d’œuvre).
• Les livrables de la phase spéc, constituent une base solide pour
l’estimation des ressources nécessaires (temps, cout, équipement,
qualifications des développeurs,…).
• Eviter l’incompréhension (généralement les besoins du client
sont imprécis et changeants).
2- Spécifications: Difficultés
2- Spécifications: Difficultés
 Les erreurs dans les exigences sont plus fréquentes que celles de
conception et d’implémentation.
 Elles sont également les plus difficiles et les plus coûteuses à
corriger a posteriori. Il est donc important de les repérer le plus
rapidement possible.
 Deux pratiques différentes s’opposent sur la manière de traiter le
problème d’expression imprécise des besoins du client:
• Faut-il faire un effort pour préciser et figer le besoin du client
en début de projet ? (Cycle en V)
• Faut-il développer de manière à être tolérant aux imprécisions
et aux changements de besoins ? (Méthodes Agile)
2- Spécifications: Livrable des spécifications détaillées
Plan type (norme IEEE 830)
1. Introduction: présentation générale, motivations, définitions des termes
2. Contexte: environnement matériel et humain, acteurs et utilisateurs, interaction avec d’autres
systèmes existants.
3. Spécifications fonctionnelles: grandes fonctionnalités du système, acteurs et autres systèmes
qu’elles impliquent
4. Spécifications non fonctionnelles et contraintes:
- Matériel (SoC, µC, DSP, …) : marques, mémoires(RAM, ROM, flash), I/O,...
- Système d’exploitation: open source, commercial, embarqué, …
- Interfaçage : protocoles de communication, débit de connexion Internet, formats de fichiers, etc.,
pour l’interaction avec des matériels, logiciels, systèmes d’exploitation...
- Performances : Système interactif, Système temps réel (dur ou souple)...
- Sécurité : sauvegardes, confidentialité, ...
- Charge à supporter : volume des données, nombre d’utilisateurs simultanés, ...
- Comportement en cas de panne...
5. évolutions à prévoir
6. annexes
Rédaction des spécifications
 Normes selon les domaines: Exemple norme IEEE 830 (1998) pour la rédaction
des spécifications (médical, automobile,…);
 organisation : Utilisation des tableaux, schémas, exemples. . . Pas uniquement
de texte (ce n’est pas un roman !) ;
 Utilisation des méthodes d’analyse: Exemple UML
• Diagrammes des cas d’utilisation UML pour représenter les fonctionnalités
et les acteurs qu’elles impliquent ;
• Diagramme de séquence UML pour représenter l’enchainement des
interactions.
Rédaction des spécifications: Exemple
Un Guichet Automatique de Banque (GAB) offre les
services suivants :
 Distribution d’argent à tout Porteur de carte de
crédit, via un lecteur de carte et un distributeur de
billets.
 Consultation de solde de compte, dépôt en
numéraire et dépôt de chèques pour les clients
porteurs d’une carte de crédit de la banque.
 Un opérateur de maintenance se charge de la
collecte des dépôts d’argent et de la recharge du
distributeur.
Besoins d’interface Homme/Machine (IHM)
 Les dispositifs d ’entrée/sortie à la disposition du Porteur de carte doivent
être :
• Un lecteur de carte bancaire.
• Un clavier numérique (pour saisir son code), avec des touches
• "validation", "correction" et "annulation".
• Un écran pour l’affichage des messages du GAB.
• Des touches autour de l’écran pour sélectionner un montant de retrait
• parmi ceux qui sont proposés.
• Un distributeur de billets.
• Un distributeur de tickets.
3- Conception (Comment?)
Phase Conception
Description  Organiser le système afin qu’il puisse satisfaire les exigences
de la spécification.
 Décrire comment tester le système.
Entrées Spécifications détaillées
Sorties Livrables:
 Une description des décisions de conception.
 Des procédures de tests qui permettent de vérifier que les
décisions de conception sont correctement implémentées et
qu’elles contribuent à satisfaire les exigences de la
spécification.
Intervenants Architectes du système (Maitre d’œuvre)
 Conception architecturale
 Décomposer le système en sous-systèmes
 Définir les interfaces, les liens entre les sous système
Résultat: Une description de l’architecture du système.
 Conception fonctionnelle
 Détailler le fonctionnement des sous-systèmes
 Définir les algorithmes et la représentation des données
Résultat: Une description fonctionnelle du système.
 Elaboration des plans de test
Comment vérifier que les sous-systèmes réalisés sont bien conformes à leurs
descriptions.
 Conception architecturale
Une description de l’architecture du système.
 Conception détaillée
 Détailler le fonctionnement des sous-
systèmes.
 Définir les algorithmes et la représentation
des données.
Résultat : pour chaque sous système, le résultat
consiste en
 Un dossier de conception détaillée.
 Un dossier de tests (les plans de test):
comment vérifier que les sous systèmes
réalisés sont bien conformes à leurs
descriptions. Plan détaillé
Exercice 1
Donner la description et les entrées/sorties des phases suivantes:
 Spécification
 Conception
 Implémentation (codage et réalisation)
 Tests unitaires
 Qualité d’une conception
 Les dégradations de la conception sont liées aux modifications

des spécifications,
 Ces modifications sont à faire vite et par d’autres que les

concepteurs originaux
• ça marche mais sans respect de la conception initiale
• corruption de la conception (avec effet amplifié au fur et à
mesure)
 La composante la plus importante de la qualité d’une conception

est la maintenabilité.
• maximiser la cohésion à l’intérieur des composants
• minimiser le couplage entre ces composants
 Pour qu’un SE soit extensible et réutilisable, il faut qu’il soit
découpé en modules faiblement couplés et à forte cohésion.
 Couplage
Une entité (sous système, fonction, module, classe, package, composant) est
couplée à une autre si elle dépend d’elle.
 Couplage faible
• Désigne une relation faible entre plusieurs entités (sous systèmes, classes,
composants), permettant une grande souplesse de
programmation/implémentation, de mise à jour.
• Ainsi, chaque entité peut être modifiée en limitant l’impact du
changement au reste du système.
 Couplage fort
au contraire, tisse un lien puissant qui rend l’application plus rigide à toute
modification de code.
 Couplage fort
 Couplage faible
 Forte cohésion
• Cohésion entre modules dans un composant, entre services dans
un module: qui se ressemble s’assemble.
• L’idée est de vérifier que nous rassemblons bien dans une classe
des méthodes cohérentes, qui visent à réaliser des objectifs
similaires.
 Forte cohésion
• Mauvais exemple : il serait mal venu d’implémenter une
méthode "Afficher()" ou "Tracer()" puisque l’objectif de cette
classe est de représenter le modèle d’un compte en banque et non
celui d’une fenêtre graphique ou d’un service de journalisation.
Cycle de développement d’un système embarqué
 Le cycle de vie de
développement d’un
système embarqué suit
plusieurs niveau
(phases) d’abstraction.
 Au fur et a mesure
qu’on progresse dans
les phases, le modèle
devient plus concret
(raffinement).
Les niveaux
d’analyse
ou de
conception
Les niveaux
de validation
Exercice 2
On souhaite développer un récepteur GPS (récepteur) pour
l’assistance de conducteur par indication de la position du
véhicule sur la carte.
1. Spécification:
1.1. Donner les spécifications du système?
1.2. Donner un diagramme de contexte (acteur, les systèmes
externes)?
1.3. Donner le diagramme des cas d’utilisation du système?
2. Conception:
2.1. Donner une architecture système?
2.2. Donner une architecture hardware?
2.3. Donner une architecture software?
Exercice 2 (correction)
1- Spécifications du système
1.1. Spécifications du système (axes à détailler)
• Objectif: Assistance de conducteur par indication de la
position du véhicule sur la carte.
• Input: 1 bouton Marche/Arrét.
• Output: Affichage position sur écran LCD 400 x 600 pixels.
• Performance: Mise à jour de la position sur écran chaque
0,25 sec.
• Alimentation: < à 100 mW.
• Dimensions physiques: < à 2’’ x 6’’.
1.1. Spécifications du système (axes à détailler)
• Déterminer la position (cordonnées) des émetteurs (satellites)
• Déterminer les caractéristiques du signal transmis par les
émetteurs (satellites): puissance d’émission, condition météo, …
• Caractéristique de la carte numérique: résolution, affinement de
l’affichage (quartier, rue,…),…
• Description de l’interface user
• Technique de calcul de position et évaluation de la précision
• …
1.2. Diagramme de contexte
Véhicule
Emetteur
Conducteur fixe 1
Récepteur
GPS
Emetteur
fixe 2
Emetteur
Agent de maintenance fixe 3
1.3. Diagramme cas d’utilisation
Visualiser la position sur carte
Faire des zoom +/-

Conducteur
Mettre à jour la position
Changer les paramètres interface
Agent de maintenance
Maintenir le système
2.1. Architecture système
2.2. Architecture matérielle
2.3. Architecture logicielle
Calcul position
Affichage
(x,y,z)
Mise à jour de la carte

chaque 0,25 sec
II. Cycle de vie d’un système embarqué
1. Cycle de vie en cascade
Le modèle en cascade (Waterfall model) est le plus classique des cycles de
vie:
 Le projet est découpé en phases successives dans le temps.
 A chaque phase correspond une activité principale bien précise produisant
un certain nombre de livrables.
 Chaque phase ne peut remettre en cause que la phase précédente.
 Aucune préparation des phases de vérification.
Spécifications
Conception
préliminaire
Bien adapté lorsque
les besoins sont Conception
clairement identifiés et détaillée
stables.
Implémentation
Intégration
Validation
Inconvénients
 Les vrais projets suivent rarement un développement séquentiel
 Établir tous les besoins au début d’un projet est difficile
 Aucune préparation des phases de vérification
• Obligation de définir la totalité des besoins au départ
• augmentation des risques car validation tardive : remise en
question coûteuse des phases précédentes
 Sensibilité à l’arrivée de nouvelles exigences : refaire toutes les
étapes
 Bien adapté lorsque les besoins sont clairement identifiés et stables
2. Cycle de vie en V
A ce jour, le cycle en V reste le cycle de vie le plus utilisé. C’est un

cycle de vie orienté test :
 A chaque phase créative (spécification, conception et
implémentation) correspond une phase de vérification (validation,
intégration, tests).
 Chaque phase en amont prépare la phase correspondante de
vérification (la vérification est prise en compte au moment même
de la création).
Les phases courantes et problèmes traités :
Spécifier Valider
Qu’est-ce que le SE doit faire? Le SE fait-il ce qu’il doit faire?
Comment s’assurer qu’il le fait? Développe t on le bon logiciel?
Comment s’assurer qu’on développe le bon SE?
Concevoir Intégrer
Comment organiser le SE pour qu’il fasse ce Le SE est-il organisé et construit de
qu’il doit faire? manière à faire ce qu’il doit faire?
Quelles choix techniques faut-il faire pour que le
SE fasse ce qu’il doit faire?
Comment s’assurer que le SE est organisé et
construit de manière à faire ce qu’il doit faire?
Implémenter: Coder/Réaliser Tester unitairement
Comment traduit-on cette organisation en code Le code source est-il bien écrit?
source et hardware?
Tests
Spécifications
de validation
Conception Tests
préliminaire d’intégration
Conception
Tests unitaires
détaillée
3 types de tests:
Codage et réalisation - Tests unitaires
- Tests d’intégration
- Tests de validation
Codage et réalisation
Quelques exemples industriels:
 Programme Aérospatiale ISO (lnfrared Space Observatory) : ensemble de
satellites destinés à une observation de l’espace dans un domaine infrarouge.
• Programme spatial de l’union européen: Lancement 1995, fin mission 1998
• Spécifications et conceptions : SART et HOOD
• Langages : Ada (15 000 lignes), Assembleur (11 000 lignes)
 Programme de ministère de la défence français SENIT8 (Dassault Électronique
& DCN-Ingénierie) : équipements de gestion et de contrôle-commande du porte-
avions Charles de Gaulle (1996).
• Spécifications et conceptions : SART et Ada-Buhr (proche de DARTS)
• Langages : Ada (1 000 000 lignes), C (400 000 lignes)
 Programme Rafale (Dassault Électronique) : avion militaire
• Spécifications et conceptions : SA-RT et OMT
• Langages : Ada (800 000 lignes à 1 500 000 lignes selon les versions).
 Avantages
La préparation des dernières phases (validation-vérification) par les premières
(conception du SE), permet d’éviter d’énoncer une propriété qu’il est
impossible de vérifier objectivement après la réalisation.
 Inconvénients
 Construit-on le bon système ? Le système embarqué est utilisé très (trop)
tard.
• Il faut attendre longtemps pour savoir si on a construit le bon système.
• Difficile d’impliquer les utilisateurs lorsque qu’un système embarqué
utilisable n’est disponible qu’à la dernière phase
 Idéal quand les besoins sont bien connus, quand l’analyse et la conception
sont claires
2. Cycle de vie en V : Livrables des différentes phases
3. Cycle de vie en W
Le développement de la partie software est souvent réalisée sur une

plateforme dite « hôte » qui n’a aucun rapport avec l’environnement
d’exécution « cible »:
 Le comportement du programme sur l’architecture hardware cible
peut être différent (compilateur croisé), et amener à des
modification du la partie software.
 Le besoin d’une simulation de comportement réel, conduit à
modifier le cycle en V par un cycle en W.
3. Cycle de vie en W
III. Validation, vérification et tests (VVT)
1- Définitions
• Processus de test (testing): processus consistant en toutes les activités du
cycle de vie, concernant la planification et l’évaluation du système
embarqué, pour déterminer s’ils satisfont aux exigences, pour démontrer
qu’ils sont aptes aux objectifs et pour en détecter des anomalies [CFTL].
1- Définitions
• Test: un ensemble d’un ou plusieurs cas de tests [IEEE 829].
• Cas de test : un ensemble de valeurs d’entrée (données de tests), de pré
conditions d’exécution, de résultats attendus et de post conditions
d’exécution, développées pour un objectif ou une condition de tests
particulière, tel qu’exécuter un chemin particulier d’un programme ou
vérifier le respect d’une exigence spécifique [IEEE 610].
2- Types de tests
 Tests unitaires : On teste chaque fonction de chaque module (tests
« boîte blanche » sur les instructions).
 Tests d’intégration: On teste les interfaces entre modules (tests «
boîte blanche » sur les interfaces, tests « boîte noire » sur les
instructions), on dit que c’est des tests « boite grise».
 Tests de validation: On teste les fonctionnalités du système (tests «
boîte noire »).
Positionnement des types de tests
Principes VVT
 Tester exhaustivement un logiciel est généralement impossible.
 Phénomènes combinatoires et coûts exponentiels
 Tester correctement un logiciel est une tâche difficile qui requiert
intelligence et créativité
 Choix de stratégies, critères d’arrêt + Connaissance indispensable du
contexte d’emploi réel
 La planification sérieuse de la VVT est indispensable à la maîtrise du
projet:
 Chaque phase du projet a sa propre VVT afin d’éviter l’effet d’avalanche
lors de l’intégration.
Principes VVT
 le but des tests est de montrer que le système fonctionne.
 le but des tests est de montrer que le système ne fonctionne pas.
 la testabilité du système est complètement intégrée au processus de
conception.
 Il est futile de « concevoir » ce que l'on ne saura pas tester
Pièges VVT:
• croire que c’est simple et facile par rapport à la programmation jugée
plus « noble »
• croire que cela n’exige ni expérience, ni savoir-faire, ni méthodes et
qu’il est inutile de planifier cette activité
Parmi tous les tests possibles, identifier ceux qui sont véritablement
pertinents pour le système à tester
 Construction de l'ensemble générateur
 Critères de construction
• Différents niveaux de couvertures selon la fréquence
d'emploi et/ou la criticité de l'élément.
• Conditions de «bord» (i.e. contraintes) sur les données des
domaines d'entrées et/ou de sorties.
• Consommation des ressources critiques (temps, mémoire,
I/O,…).
 L’activité de VVT débute dès la première phase
expression besoin et spécifications (voir cycle en V).
 Parmi les acteurs, il faut distinguer ceux qui introduisent

les défauts, et ceux qui recherchent les défauts pour les
corriger
 Parmi les acteurs, il faut distinguer ceux qui introduisent les défauts, et ceux qui
recherchent les défauts pour les corriger:
 Le chef de projet: Planification des tâches et assurance qualité (système
qualité)
- Organisation de l’équipe
- Mise en œuvre de la stratégie et des méthodes.
 L’architecte du projet: au sens large = expression de besoin
- Spécification
- Conception
 implique le MO et/ou le client.
 Les programmeurs/designers/ testeurs:
- Conception détaillée et programmation
- Composants logiciel/hardware {Données+Algorithmes +Contrôles} intégrables (i.e.
documentés et testés)
MOE/MO
Tests de validations
Exercice 3
Quels est l’input, l’output et l’intervenant dans les activités
suivantes:
 Tests unitaires
 Tests d’intégration
 Tests de validation
Exemple de tests de validation (plan des tests)
une partie ID test Description Scénario Résultat Résultat
des attendu actuel
spécifications
1 Ouverture d’un 1- Saisir code Document
état de sortie client; ouvert et
2- Cliquer sur prêt a être
bouton manipuler.
recherche;
3- Clique sur
bouton afficher
situation.
2 Modification
donnée client
 Plans des tests de validation sont élaborés avant conception et programmation.
 Sélection des tests à partir d’une spécification du système (fonctionnelle ou non
fonctionnelle), sans connaissance de l’implémentation.
Une partie des Résultat

spécifications attendu
sélection Verdict
Tests Système Résultat

exécution (boite noire) de test
Un test de validation pour un distributeur de café (réalisation des tests).
Une partie de spécification:

Café=20 c,
Thé=50c Résultat attendu:
- Pièce puis boisson Obtenir un thé
- Ne rend pas la monnaie
Sélection:
Verdict:
Test ID 10 Echec
Test ID:10
Système Résultat de test:
On peut acheté un
thé à 50 c Exécution: (boite noire) On obtient un café
Insérer 50c

Chap 2 Cycle Vie SE

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chap 2 Cycle Vie SE

Transféré par

Droits d'auteur :

Formats disponibles

Conception et programmation des

I- Processus de développement d’un SE

 Le développement et l’évolution d’un SE doit être vu comme un

 Principe: « Diviser pour mieux régner. »

Chaque phase est décrites en termes de :

Les phases courantes et problèmes traités :

1- Etude préalable de faisabilité

 Les dégradations de la conception sont liées aux modifications

 Ces modifications sont à faire vite et par d’autres que les

 La composante la plus importante de la qualité d’une conception

Faire des zoom +/-

Changer les paramètres interface

Mise à jour de la carte

A ce jour, le cycle en V reste le cycle de vie le plus utilisé. C’est un

Le développement de la partie software est souvent réalisée sur une

 Parmi les acteurs, il faut distinguer ceux qui introduisent

Une partie des Résultat

Tests Système Résultat

Une partie de spécification:

Vous aimerez peut-être aussi