Lycée: lissane eddine laayoune
Filière: BTS DSI
Atelier de génie logiciel
Pr H.LAARAJ
[email protected]
http://lewebpedagogique.com/laarajbts
2015/2016
1
Plan du cours
I. Introduction
II. Principes de génie logiciel
III. Modèles , processus
IV. Spécification
V. Atelier de génie logiciel(outils CASE)
2
I.1- activité:
La différence entre un programme et un logiciel?
Programme Logiciel
créer par un individu la fabrication collective
unique difficile
facile concrétisée par les
peut être produit sans documents , conception,
conception programmes et de jeux
de tests
multiples versions 4
I.2- definition:
Le génie logiciel est un domaine des
sciences de l’ingénieur dont l’objet
d’étude est la conception, la fabrication
et la maintenance des systèmes
informatiques complexes
5
I.3- objectifs:
Activité:
Seulement 15 % des applications écrites
sont mises en place et fonctionnent !
(selon des enquêtes réalisées aux USA)
Pourquoi ?
6
Pourquoi?
Retards de livraisons
Dépassements de budgets
Technologies en mutation
Complexité des applications
Evolution des spécifications en cours de
développement
7
Objectifs de GL
assurer que les 4 critères suivants soient satisfaits
Fonctionnalités Le système qui est fabriqué répond aux
besoins des utilisateurs
La qualité correspond au contrat de service initial
Les coûts restent dans les limites prévues au départ.
Les délais restent dans les limites prévues au départ.
Règle du CQFD : Coût Qualité Fonctionnalités Délai.
8
II- Principes de génie logiciel
10
II.1- sept principes fondamentaux
Cette partie liste sept principes fondamentaux
(proposés par Carlo Ghezzi):
rigueur
séparation des problèmes
modularité
abstraction
anticipation du changement
généricité
construction incrémentale
11
rigueur
le résultat d'une activité de création d’un
logiciel peut être évalué rigoureusement,
avec des critères précis, exact.
En pratique:
Utilisation au maximum de lois
mathématiques précises
Suivi à la lettre de techniques formelles
(MCD, UML,…)
12
séparation des problèmes
C’est une règle de bons sens qui
consiste à considérer séparément
différents aspects d’un problème afin
d’en maîtriser la complexité
diviser pour régner
13
séparation des problèmes
Séparation dans le temps avec la notion de
cycle de vie du logiciel.
Séparation des qualités que l’on cherche à
optimiser à un stade donné.
Séparation des vues que l’on peut avoir
d’un système.
14
séparation des problèmes
Exemple: Comment créer dynamiquement une page
internet pour visualiser et modifier le contenu d’une BD
sans la bloquer?
Solution:
Décomposition en trois composants:
Modèle: son rôle est gérer le stockage des données.
Vue: son rôle est visualiser les données.
Contrôleur: son rôle est de n’autoriser que les
modifications correctes.
15
modularité
Un système est modulaire s’il est composé
de sous-systèmes plus simples(modules)
système Module 2
Module 1 Module3
16
abstraction
L'abstraction se réfère à la distinction entre les
propriétés externes d'un système et les détails de sa
composition interne
L'abstraction permet de gérer des systèmes très
complexes en connaissant seulement les choses qui
nous intéressent à un moment donné
Abstraction
17
anticipation du changement
Un logiciel est presque toujours soumis à
des changements continuels
Ceci requiert des efforts particuliers pour
prévoir, faciliter et gérer ces évolutions
inévitables.
18
généricité
Il est parfois avantageux de remplacer la
résolution d’un problème spécifique par la
résolution d’un problème plus général. Cette
solution générique pourra être réutilisée
plus facilement
Des solutions génériques (paramétrables,
adaptables) sont plus facilement réutilisables.
Classes génériques<>, héritage,…
19
construction incrémentale
Un procédé incrémental atteint son but par
étapes en s’en approchant de plus en plus;
chaque résultat est construit en étendant le
précédent.
Par exemple : pour les logiciels plus
complexes on réalise d’abord un noyau des
fonctions essentielles et on ajoute
progressivement les aspects plus secondaires.
20
III modèles
21
III.1 exemple des modèles
Modèles en cascade
Modèles en V
Modèle en spirale
Modèles incrémentaux
…
22
III.2 le cycle de vie d'un logiciel :
Analyse des besoins (Expression des besoins du produit)
Spécification globale (Conception préliminaire, au niveau
système)
Conception architecturale et détaillée
Implémentation (Programmation ou Phase de codage)
Gestion de Configuration et Intégration
Validation et Vérification
Maintenance et Assistance
23
III.3 Répartition de l’effort
24
Analyse des besoins
La première étape du cycle de
développement d'un logiciel consiste à
produire un document qui décrit les
utilisateurs visés et leurs objectifs.
« Que doit-on faire et qui utilisera le
produit ? ».
25
Analyse des besoins
Mise du logiciel dans son contexte :
type de produit , les objectifs des
clients.
Etude de l’existant :
Etude des produits similaires dans le
marché
Critiquer les produits concurrents
Etude du processus/logiciels existants à
l’entreprise
26
Spécification Globale
(Conception préliminaire)
C'est une description de haut niveau du
produit, en termes de « modules » et
de leurs interactions.
« ce que doit faire le logiciel »
27
Conception Architecturale et
Détaillée:
C'est au niveau de la conception détaillée que
chacun des modules énumérés dans le dossier
de conception préliminaire est décrit en détail
Deux choses doivent émerger lors de cette
étape : un diagramme de PERT ou de GANTT,
montrant comment le travail doit être fait et dans
quel ordre, ainsi qu'une estimation plus précise de
la charge de travail induite par la réalisation de
chacun des modules.
28
Implémentation
(Programmation):
Chacun des modules décrits dans le
document de spécification détaillé doit
être réalisé(programmé).
31
Gestion des Configurations et
Intégration:
Appelée aussi phase de déploiement.
Quand tous les modules sont terminés,
l'intégration, au niveau du système, peut
être réalisée. C'est là que tous les modules
sont réunis en un seul ensemble de code
source, compilés et liés pour former un
paquetage qui constitue le système.
32
Validation et Vérification:
La validation est basée sur les besoins que le
produit doit satisfaire, et permet de mettre en
évidence de défauts.
Valider c'est répondre à la question : "Faisons
nous le bon produit?"
La vérification a pour fonction la mise en
évidence d'erreurs.
Vérifier c'est répondre à la question "Faisons
nous le produit correctement?"
33
Maintenance et assistance:
Les défauts du logiciel rencontrés, soit pendant la
phase de test soit après sa diffusion, doivent être
enregistrés dans un système de suivi.
Il faudra affecter un ingénieur logiciel pour la
prise en charge de ces défauts, qui proposera de
modifier soit la documentation du système, soit la
définition d'un module ou la réalisation de ce
module.
34
III.4 Le Modèle en Cascade:
consiste en une succession de phases dont
chacune est méthodiquement vérifiée avant
de passer à l'étape suivante :
Le principe de modèle en cascade est de
découper le projet en phases distinctes sur le
principe du non-retour. Lorsque une phase
est achevée, son résultat sert de point
d'entrée à la phase suivante.
35
schéma Modèle en cascade
Etude préliminaire
Projets de petite taille
Analyse des besoins
Analyse du système
Conception du système
Développement
Tests
Installation
Maintenance 36
Modèles en Cascade
Avantages
Simple et facile à comprendre
Force la documentation : une phase ne
peut se terminer avant qu’un document
soit validé
Les progrès sont tangibles (pour
l’équipe de développement)
37
Modèles en cascade
Limites
Le produit final est la première chose que
voit le client
Ne marche que si les besoins sont stables
et le problème connu
ne traite pas les évolutions
Problèmes découverts en phase de
validation
38
III .5 Modèle en « V »
(variante du modèle en cascade)
L'assurance qualité est le processus qui permet de vérifier en continu
la qualité du produit à fur et à mesure de sa fabrication.
Le modèle en V met l'accent sur ce processus. Il confronte les
différents niveaux de test avec les phases de projet de même niveau.
Ceci permet à chaque étape de définir non seulement les fonctions,
mais également les critères de validation.
La cohérence entre les deux éléments permet de vérifier en continu
que le projet progresse vers un produit répondant aux besoins
initiaux.
Ce modèle est adapté aux projets de taille et de complexité moyenne.
39
Le modèle en «V»
40
III.6 Modèles incrémentaux
L’environnement technique et économique
évolue
Les besoins et les souhaits des clients
changent
Les priorités du management aussi
les méthodes en cascade ne marchent pas
On ne peut pas attendre de tout savoir pour
commencer
41
Principes des modèles
incrémentaux
Diviser le projet en incréments
Un incrément = une sous partie fonctionnelle
cohérente du produit final
Chaque incrément ajoute de nouvelles fonctions
Chaque incrément est testé comme un produit
final
Les incréments sont définis a priori
42
Modèles incrémentaux
La première version constitue le noyau
Les versions suivantes s’appuient sur l’existant et
étendent l’architecture
Chaque version donne lieu à un cycle de vie complet
cycle de cycle de
vie vie
complet complet
Version 1 43
Version 2 Version 3
Modèles incrémentaux
Avantages
Une première version du système est fournie
rapidement
Réduit le stress du management !
Les risques d’échec sont diminués
Découverte des problèmes assez tôt
Les parties importantes sont fournies en premier
et seront donc testées plus longuement
Les clients peuvent ajouter des besoins à tous
moments
44
Modèles incrémentaux
Limites
Difficile à définir les incréments:
Difficile de concevoir une architecture
stable dès le début ou facilement
évolutive
Ne traite pas toutes les évolutions,
notamment celles qui remettent en
cause l’architecture
45
Synthèse:
Un cycle de vie apporte stabilité, contrôle et
organisation des activités
meilleure estimation des coûts et besoins
meilleure coordination
meilleure productivité
meilleure visibilité et compréhension
49
IV- spécification
50
IV.1- définition (spécification)
Tout produit complexe à construire doit
d’abord être spécifié ; par exemple un pont
de 30 mètres de long, supportant au moins
1000 tonnes, construit en béton, etc. Ces
spécifications peuvent être considérées
comme un contrat entre un client et un
producteur
De manière générale une spécification décrit
les caractéristiques attendues (le quoi) d’une
implantation (le comment).
51
IV.2 Les techniques de spécification pour
les phases d’analyse
Les spécifications en langue naturelle: elles
manquent de structuration, de précision et sont
difficiles à analyser.
Les spécifications semi formels: pour spécifier
des systèmes par des langages spécialisés(ADA, UML,
DFD,…).
Formelle : quand la syntaxe et la sémantiques sont
définies formellement par des outils mathématiques
52
IV.3 Les diagrammes de flots de données
(DFD)
Il s’agit d’une technique semi-formelle
et opérationnelle. Les DFD décrivent
des collections de données manipulées
par des fonctions.
Les données peuvent être persistantes
(dans des stockages) ou circulantes
(flots de données).
53
Diagramme DFD
La représentation graphique classique distingue :
les fonctions par des cercles
les stockages par des boîtes ouvertes
les flots par des flèches
les entités externes par des rectangles
54
Exemple: DFD d’un guichet bancaire
Vérifier les Clients
carte informations du
+passwd client
Les infos
correctes
Client Somme à tirer Comptes
Choisir la
somme
Solde Argents
argent
suffisant
sortir
l’argent
55
IV.4 diagramme de contexte
Au niveau le plus abstrait, on peut se
contenter des entités à l’interface
(‘acteurs’) et des flots qu’ils
s’échangent, sans décomposition en
fonctions. On parle alors de ‘diagramme
de contexte’
56
Exemple : diagramme de contexte d’un
guichet bancaire
carte
passwd
Client
Somme à tirer
Guichet
argent
57
Exercice: On s'intéresse au processus des emprunts des
livres dans une bibliothèque.
Un étudiant se présente au guichet pour emprunter un livre, donne à
l'employé de la bibliothèque la référence du livre voulu.
l'employé demande à l'étudiant sa carte qui sera saisie à l’aide d’un
lecteur optique (lecture du code à barres).
Il vérifie ensuite si le livre est déjà emprunté ou non.
Si le livre est présent dans la bibliothèque, il le donne à l'étudiant et
met à jour la base de données.
Si le livre est emprunté, il retourne à l'étudiant la date à laquelle il
pourra avoir le livre. Il met à jour ensuite le statut du livre dans la
base de données.
1- Donner le DFD?
2- Donner le diagramme de contexte?
58
Correction:
1-Diagramme DFD
Date de retour Mise à jour
emprunté
existe
Ref livre Vérifier
Etudiant l’existence du Livres
carte
livre
Date de Non existe
réservé
disponibilité
Mise à jour
59
Correction:
2- diagramme de contexte
carte
Ref livre
Etudiant
Date de retour
Bibliothèque
Date de
disponibilité
60
V- Atelier de génie logiciel
AGL ou bien (outils CASE)
61
V.1 – AGL (outils CASE)
Un logiciel (Outils CASE Computer Aided
Software Engineering) aidant à la réalisation de
logiciels
Il est basé sur des méthodologies qui formalisent
le processus logiciel
Il contribue à l'amélioration de la productivité et
de la qualité du logiciel
Exemple : Windev , visual studio, netbeans, …
62
V.2- les composantes de AGL
Exploitation
Analyse Conception Codage Test et
Maintenance
Debuggers
Editeur de Compilateur Outils de
Editeur de Logiciel de
texte et de Générateurs génération
texte et de gestion de
diagrammes d'interfaces de tests
diagrammes configuration
63
