GL PP40

VISITE RAPIDE
DU
GÉNIE LOGICIEL
C.Crochepeyre 1999 Cnam - Génie logiciel

1
PLAN
• CYCLE DE VIE D'UN LOGICIEL

• EXPRESSION DES BESOINS
• SPÉCIFICATIONS DU LOGICIEL
• CONCEPTION DU LOGICIEL
• LA PROGRAMMATION
• TESTS ET MISE AU POINT
• DOCUMENTATION
2
1. CYCLE DE VIE D'UN LOGICIEL
• Modèle général du cycle de vie

– Expression des besoins
– Conception du système et du logiciel
– Réalisation et test unitaires
– Tests du système
– Utilisation et maintenance

3
• Cycle de développement
– retour d'informations aux étapes précédentes
Besoins
Flot d'informations
arrière
Conception
Flot d'informations Réalisation

avant
Tests

4
• Cycle de vie
– étape d'utilisation et maintenance: remise en cause
des étapes précédentes
Besoins
maintenance
utilisation et
Conception
Réalisation
Tests

5
Cycle de vie en 'V'
Expression des
Validation
besoins
Conception
Intégration
préliminaire
Conception Tests
détaillée unitaires
Codage

6
• Points forts
– Vérification
• réalisation = bonne construction?
– Validation
• réalisation = bon produit?
– Coût du logiciel
• à quelle étape est-il plus important?
• comment procéder pour le réduire?

7
• Coûts
Développement en début et fin de développement
Maintenance changements et non erreurs
• Modèles de développement
évolutif prototypes
incrémental spécification formelle

8
• L'évolution des logiciels
– demande des utilisateurs
– changement de l'environnement
– versions après corrections
• Les lois d'évolution (Lehman 1976)
– changement est nécessaire
– complexité croissante est inévitable
– régulation de l'évolution est automatique
– stabilité organisationnelle du développement
– degré d'évolution constant entre 2 versions

9
• Fiabilité plus importante que efficacité
Coûts équipements
confort des usagers
Rapidité équipements
Fiabilité > Performances rejet des usagers
Type de conséquences catastrophes
Programme fiable correction difficile
Les vices cachés effets secondaires
Les rattrapages pertes d'informations

10
2. EXPRESSION DES BESOINS
• Analyse et définition des besoins du système

– analyste et ingénieur informatique
• définitions des fonctionnalités
• recensement des données
• Pas de solution technique à ce niveau

11
• Document: cahier des charges
• Modèle conceptuel
• Définition des besoins fonctionnels
• Organisation et stockage des données
• Définition des besoins non fonctionnels
• Validation

12
• Le cahier des charges
selon Heninger (1980)

– spécification du comportement externe du système
– contraintes de réalisation
– outil de référence aux programmeurs
– éléments pour les étapes ultérieures
– réponses aux événements désirables ou non
– facile à mettre à jour

13
• Le modèle conceptuel du système
– exemple des automates finis: commande,
fonctions et données
– facilité d'une représentation graphique
comptabilité
BD
comptable
paie
impression

14
• Définitions des besoins fonctionnels
– définition des services
– complétude et cohérence
– modifications lors des étapes ultérieures
• trois méthodes
– langage naturel
– langage structuré ou formaté (SADT)
– langage de spécification formelle (ADA)

15
• Organisation des données
– modèle Entité-Relation (E-R ou E-A)
– aspect conceptuel des données
– les entités, associations, attributs et identifiants
• entité: existe d'elle même
• association: existe entre entités
• attribut: propriété individuelle d'une entité ou
association
• identifiant: attribut particulier identifiant l'entité
• cardinalité: nb d'association pour une entité (0,1,n)

16
Représentation graphique E-R
point = entité partagée

dans les diagrammes
.
1-n
0-1
ASSOCIATION
1-1
0-n
ENTITÉ

17
• Définitions des besoins non fonctionnels
– contraintes sur les fonctions du système
– soumis aux évolutions technologiques
– intéraction entre fonctions: conflits -> solutions
– langage naturel ou structuré:
• matrice besoins/propriétés
propriétés vitesse mémoire

besoins
>4MO A D17 A: cas analysé
Di: définition Di
réponse <3s D84,D95 A

18
• Validation des besoins
par les utilisateurs et développeurs
– cohérence
• pas de conflit entre besoins
– complétude:
• tous les besoins et contraintes
– réalisme:
• réalisables avec la technologie matériels et logiciels
– validité:
• des fonctionnalités supplémentaires si nécessaire

19
• Le prototypage
– approche évolutive du développement

• prototype enrichi au fur et à mesure
• prototype jetable
– avantages:
• cas concret de discussion
• détection des fonctions manquantes
• amélioration des fonctions complexes
• démonstration de la faisabilité
• utilisation comme spécification d'un système

20
• inconvénients du prototypage:
– coût de développement
– incite les changements côté utilisateur
• à ne pas faire:
– développement du prototype avec les outils du
produit final
– développement avec le même degré de finesse
• mais:
– utiliser des outils qui permettent de
– mettre l'accent sur l'essentiel
21
• Conclusion: expression des besoins
– Définition des services attendus par l'utilisateur

– Analyse des fonctions et de leurs contraintes
– Pas encore de solutions techniques
– Collaboration de l'utilisateur importante
– Utilisation de modèles, méthodes ou de techniques:
statiques ou dynamiques
– Validation correcte avant la phase suivante
– Définir les limites
– Envisager les évolutions
22
3. SPÉCIFICATIONS DU LOGICIEL
• Passage:
– de l'expression des besoins à la conception
• Spécifications fonctionnelles
• Conception des logiciels
• Relations entre les logiciels
• Détails des logiciels

23
• Document de spécifications des logiciels
– définitions abstraites des logiciels
– destiné aux développeurs
• Outils de spécifications des logiciels:

– domaine de la recherche
– orientation vers des techniques formelles
– définition du langage de spécification
– approches différentes de spécifications

24
• Définition des langages de spécification
– approche opérationnelle
• définition d'une machine abstraite
• définitions des opérations de cette machine
– approche dénotationnelle
• définitions de fonctions par logique mathématique
• espace de valeurs abstrait
• propriétés des valeurs décrites par des techniques
mathématiques
– approche axiomatique
• constructions de fonctions basées sur des axiomes

25
• Les approches différentes de spécification
• Spécifications d'interface
– logiciel = boîte noire
– fonction de la boîte = contraintes E/S
E
logiciel
S

26
• Spécifications opérationnelles
– description abstraite des transformations E/S
– description des opérations du programme
E
logiciel
S

27
• Spécifications de types abstraits

– type abstrait = valeurs et opérations associées
– description du comportement des opérations sur
chaque type abstrait
– approches:
• modèle abstrait
• modèle algébrique:
– noms des opérations,
– arguments des opérations
– axiomes de comportement des opérations

28
• Méthode Analyse Structurée SA
E. YOURDON (1979)
– spécification statique du logiciel

– analyse descendante:
• affinages successifs des traitements
• description des flots de données des traitements
• ensemble de diagrammes ordonnés et hiérarchisés
• fonctions élémentaires = primitives fonctionnelles
– outils graphiques et textuels

29
• Méthode SA Temps Réel SA-RT
P. WARD et S. MELLOR (1985)
– extension de SA au temps réel

• méthode SA: vue statique des process
• méthode SA_RT: vue dynamique des process
– systèmes temps réels:
• systèmes combinatoires: E => S
• systèmes séquentiels: E + états internes => S
– outils graphiques et textuels

30
• Méthodologie d'analyse TR
– expression des besoins:

• méthodes statiques: SADT ou EA
• méthodes dynamiques: réseaux de Pétri ou SA_RT
– spécification du logiciel: modèle essentiel
• modèle d'environnement
– diagramme de contexte
– liste des événements externes
• modèle de comportement
– aspects statiques: DFD, DD, DSD, PSPEC
– aspects dynamiques: CFD, DD, CSPEC, TSPEC

31
• Conclusion: spécifications du logiciel
– des méthodes différentes mais:

• des outils similaires (graphes, textes, tables)
• des besoins différents (statique ou dynamique TR)
• des niveaux différents (besoins, logiciels)
• des apprentissages plus ou moins faciles
– de la spécification fonctionnelle du logiciel à sa

conception préliminaire et détaillée

32
4. CONCEPTION DU LOGICIEL
• Conception impérative
– fonctionnelle descendante
– modulaire
• Conception applicative
– orientée objets
– héritage

33
• Conception du logiciel
– transformation en unités de programmes des

fonctionnalités du logiciel
• conception fonctionnelle descendante
• conception orientée objet
• conception orientée données
– éléments de conception
• concepts de structuration
• méthodes de conception
• langages de programmation

34
• Les concepts de structuration
– la modularité
• décomposition impérative: le module
• décomposition applicative: la classe d'objet
– l'abstraction
• vues différentes d'un constituant selon les besoins
– le masquage de l'information
• vues externes différentes d'un constituant
– la hiérarchie
• relations orientées entre constituants

35
• Conception fonctionnelle descendante
impérative
– module
• unité fonctionnelle reliée aux données
• langages: Ada, C, Modula 2
– décomposition d'un module:
• l'interface: spécifications des composants exportés
• le corps: composants réalisants les fonctionnalités
– méthode SASD

36
conception modulaire
module A
IMP f(x) module B
module B
EXP f(x)

37
• la hiérarchie des modules

38
• Les types de modules
– modules de données
• gestion de données statiques
• gestion de données dynamiques
– modules de traitements
• entité d'exécution parallèle
• communications et synchronisation entre processus
– modules fonctionnels
• imbrications de modules données, traitements et
communications
• composants élémentaires

39
– modules de communications
• interface de communications entre modules de
traitements
• communications externes ou internes
– couches
• architecture en couches

40
• Conception orientée objets
applicative
– les fonctions changent - les objets restent

– penser réutilisation
– unité de conception = classe d'objets
– langages: C++, Java
– méthodes OOD et HOOD
"Sur quoi le système agit-il?"

41
• Un objet, c'est:
– ensemble d'attributs soumis à des actions
spécifiques
• les attributs -> état de l'objet
• les actions -> les méthodes
• il a un comportement:
– déterminé par ses actions
– avec des contraintes sur les actions ou attributs
– représenté par:
• réseaux de pétri, automates à états finis, des
diagrammes, des matrices, des grafcet....

42
• Classe d'objets
– ensemble d'objets
• mêmes attributs statiques
• mêmes attributs dynamiques
– une instance est un objet particulier de la classe
• crée avec les attributs d'états de la classe
• se comporte selon les méthodes de la classe
classe COMPTE_CLIENT:
Code client: n° du compte client
Titulaire: nom et adresse du client
Solde: montant disponible
Débiter: procédure de retrait sur le solde
Créditer: procédure d'ajout sur le solde

43
• Héritage
– les sous-classes: organisation hiérarchique

– héritage des champs et des méthodes
• extension des champs et méthodes de la classe dans
la sous-classe
• évite la duplication de code
– héritages:
• simple: nouvelle classe issue d'une classe origine
– de toutes les propriétés
– de certaines propriétés
• multiple: nouvelle classe issue de plusieurs classes

44
• Action sur les objets
– envoi de messages
– déclenchement de l'action
– retour ou continuation de l'action
• Dictionnaire des méthodes avec sélecteurs
– interface de traitement des messages
– recherche du sélecteur
• si oui
-> déclenchement de la procédure
• si non
-> recherche dans la super classe

45
• Conclusion
– lourdeur pour les petits projets
– ateliers de génie logiciels:
• STOOD de TNI
• HSF de SYSTEMATICA
• CONCERTO de SEMA
• HOOD_TOOLSET de IPSYS
– difficulté d'associer des méthodes (cycle de vie)
• SADT/HOOD
• SA_RT/HOOD
• JSD/HOOD

46
5. LA PROGRAMMATION
• La méthodologie
• La lisibilité des programmes
• Les outils
• La portabilité des programmes
• Les langages

47
• Méthodologies
– passage de l'analyse à la programmation
– méthodologie ascendante
– méthodologie descendante

48
• Masquage des informations
– accès aux seules informations nécessaires/programme
– appliqué dans la conception O.O
– sécurité + indépendance des données
• Lisibilité des programmes

– dépend du langage et du style d'écriture
– le choix des noms
– la mise en page des programmes
– de bonnes structures de contrôles (boucles, condition.)

49
• Les outils
– outils de préparation des programmes

• éditeurs lignes
• éditeurs plein écran
– outils de traduction
• compilateurs: bons et moins bons
– outils d'analyse
• références croisées
• mise en forme du source
• liste de partie de programme

50
– outils de gestion de configuration
• traces du développement
• étapes de maintenances des modules
• interdépendance des modules
• suivi cohérence des versions
• exemples sous Unix: SCCS et MAKE

51
• les environnements de programmation
– logiciels de communication entre

• machine développement et machine cible
– simulateurs de machine cible
– outils de tests et mise au point
• bancs de test, analyseurs de programmes
– traitements de texte
– outils de spécifications fonctionnelles
– outils graphiques de description
– outils de gestion de projets
• génération de rapports d'avancement du projet
52
• La portabilité des programmes
– la dépendance due à l'architecture machine

– la dépendance due au système d'exploitation

53
• Les langages
– les langages d'assemblage

– les langages de réalisation de systèmes: C
– les langages statiques de haut niveau: Cobol
– les langages de haut niveau à structure de blocs: Ada
– les langages dynamiques de haut niveau: Prolog
– les langages objets: C++, Java

54
6. TESTS ET MISE AU POINT
• Tests
– détection des erreurs
– abscence d'erreurs?
– choix judicieux des tests
• Mise au point
– localisation des erreurs et corrections
– mode d'écriture facilitant la mise au point

55
• Les tests
– les types de tests

• tests unitaires
• tests de modules
• tests de sous-systèmes
• tests d'intégration
• tests d'acceptation
– méthodes descendante ou ascendante

56
– la conception des tests
• ensemble de données réalistes
• spécifications entrées
+ fonctions
+ spécifications sorties
• effets des données incorrectes
• combinaisons de données
• générateur automatique de données
– les tests de programmes temps réel

• interactions entre processus
• événements externes
• opérations de tests graduelles

57
– la vérification des programmes
• correspondance entre programme et spécification
• réduction des coûts de tests
• preuve mathématique des programmes
– les inspections de codes
• lecture du code et explications devant l'équipe
– les outils de validation
• générateurs de tests
• analyseurs de flots continus
• les comparateurs de fichiers
• les simulateurs
• les vérificateurs de programmes

58
• La mise au point
– identification la cause des erreurs
– localiser les erreurs
– modifier le code
– liste des résultats de tests

– trace de l'exécution
– les outils de mise au point

• vidage mémoire
• débogueurs symboliques
• analyseurs de programmes statiques
• analyseurs de programmes dynamiques
59
7. DOCUMENTATION
• Documentation et maintenance
– les différents documents
– la qualité des documents
– les outils de production
– la maintenance des documents et logiciels

60
• Les documents d'un logiciel
Deux niveaux:
– doc interne: informaticiens
• développement du logiciel
• maintenance du logiciel
– doc externe: utilisateurs
• présentations des fonctions
• pas de détail de réalisation

61
• L'ensemble des documents
– un cahier des charges: besoins

– un dossier d'analyse fonctionnelle
– un manuel de conception
– un dossier de programmation
– un manuel d'installation et de mise ne oeuvre

– un manuel d'utilisation
– un dossier des procédures de tests

62
• La documentation utilisateur
– choisir une structure de document adaptée

• niveaux généraux et niveaux détails
– des types de documents en fonction des usages:

• réponse aux besoins
• installation
• démarrage
• fonctionnement

63
• La documentation développeurs
– la définition desbesoins
– les spécifications fonctionnelles
– les unités de programme
– les tests unitaires
– les tests d'intégration
– les tests de validation du système
– le dictionnaire de données

64
• La qualité des documents
– écriture
– présentation
– complétude
– actualisation
CHARGE IMPORTANTE

65
• Quelques conseils
– construire des phrases simples

– faire attention à l'orthographe
– une seule idée par phrase
– utiliser des références explicites en qqs mots
– présentation sous forme de tableaux ou listes
– répéter les descriptions complexes
– termes précis avec glossaire
– paragraphes courts

66
• Les outils de production de documents
– production document et logiciel sur la même
machine
• Maintenance des documents et logiciels
– modification simultanée avec le système
– numérotation -> remplacement des sections
– les types de maintenances:
• amélioration
• adaptation
• correction
– la portabilité
• la documentation doit accompagner le logiciel

67
BIBLIOGRAPHIE
• Le génie logiciel et ses applications
Ian Sommerville InterEditions 1988
• Génie logiciel: les méthodes
Patrick Jaulent Armand Colin 1994
• Le génie logiciel
Jacques Printz PUF1995
• Ateliers de génie logiciel
Tribunix Vol10 N°54 mars:avril/94
• Qualimétrie des systèmes complexes
Thomas Forse Les éditions d'organisation 1989

68
• Ateliers de génie logiciel
Tribunix Vol10 N°54 mars:avril/94
• Qualimétrie des systèmes complexes
Thomas Forse
Les éditions d'organisation 1989

69

GL PP40

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

GL PP40

Transféré par

Droits d'auteur :

Formats disponibles

VISITE RAPIDE

C.Crochepeyre 1999 Cnam - Génie logiciel

• CYCLE DE VIE D'UN LOGICIEL

• Modèle général du cycle de vie

C.Crochepeyre 1999 Cnam - Génie logiciel

Flot d'informations Réalisation

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

Développement en début et fin de développement

Maintenance changements et non erreurs

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

Programme fiable correction difficile

Les vices cachés effets secondaires

Les rattrapages pertes d'informations

C.Crochepeyre 1999 Cnam - Génie logiciel

• Analyse et définition des besoins du système

• Pas de solution technique à ce niveau

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

selon Heninger (1980)

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

point = entité partagée

C.Crochepeyre 1999 Cnam - Génie logiciel

propriétés vitesse mémoire

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

– approche évolutive du développement

C.Crochepeyre 1999 Cnam - Génie logiciel

– Définition des services attendus par l'utilisateur

C.Crochepeyre 1999 Cnam - Génie logiciel

• Outils de spécifications des logiciels:

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

• Spécifications de types abstraits

C.Crochepeyre 1999 Cnam - Génie logiciel

– spécification statique du logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

– extension de SA au temps réel

C.Crochepeyre 1999 Cnam - Génie logiciel

– expression des besoins:

C.Crochepeyre 1999 Cnam - Génie logiciel

– des méthodes différentes mais:

– de la spécification fonctionnelle du logiciel à sa

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

– transformation en unités de programmes des

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

IMP f(x) module B

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

C.Crochepeyre 1999 Cnam - Génie logiciel

– les fonctions changent - les objets restent