Génie logiciel

Analyse, Conception des

Systèmes Informatiques
• Définition
• « Ensemble de méthodes, techniques et outils
Méthode Analyse Conception pour la production et la maintenance de
composants logiciels de qualité. »
Introduction à UML
• Justifications :
• Evolution des techniques de programmation, du
matériel, des besoins

O. Boissier, SMA/G2I/ENS Mines Saint-Etienne, Olivier.Boissier@emse.fr, Septembre 2004

Génie logiciel 2

Des problèmes Des principes

• Croissance de la taille et de la complexité • Rigueur et formalisation

des systèmes
• Séparation des problèmes
• besoins et fonctionnalités augmentent, évoluent
• technologies en perpétuelle évolution
• Modularité, Abstraction
• diversification des architectures • Prévision de changements
• Avec des délais de plus en plus courts, • Généricité
• et des équipes de plus en plus grosses, avec • Incrémentalité
des compétences multiples

Génie logiciel 3 Génie logiciel 4

 Qualité du logiciel Qualité du logiciel (suite)

• Facteurs externes (cf. utilisateur) • Compatibilité

• Correction (validité) • facilité avec laquelle un logiciel peut être combiné avec d ’autres
• aptitude à répondre aux besoins et à remplir les fonctions • Efficacité
définies dans le cahier des charges • utilisation optimale des ressources matérielles (processeur,
• Robustesse (fiabilité) mémoires, réseau, …)
• aptitude à fonctionner dans des conditions non prévues au • Convivialité
cahier des charges, éventuellement anormales • facilité d ’apprentissage et d ’utilisation
• Extensibilité • facilité de préparation des données
• facilité avec laquelle de nouvelles fonctionnalités peuvent être • facilité de correction des erreurs d ’utilisation
ajoutées à un logiciel • facilité d ’interprétation des résultats

Génie logiciel 5 Génie logiciel 6

Qualité du logiciel (suite) Qualité du logiciel (suite)

• Intégrité (sécurité) • Portabilité

• aptitude d ’un logiciel à protéger son code contre des accès non
• aptitude d ’un logiciel à être transféré dans des
autorisés.
environnements logiciels et matériels différents
• Facteurs internes (cf. concepteur)
• Lisibilité,
• Ré-utilisabilité
• Aptitude d ’un logiciel à être réutilisé, en tout ou en partie, pour • Modularité.
d ’autres applications
• Vérifiabilité
• aptitude d ’un logiciel à être testé (optimisation de la préparation
et de la vérification des jeux d ’essai)

Génie logiciel 7 Génie logiciel 8

 Sommaire Projet

• Génie logiciel • Ensemble d’actions à entreprendre afin de

• Conduite de projet informatique répondre à un besoin défini dans des délais
fixés, mobilisant des ressources humaines et
• Phases de développement
matérielles, possédant un coût.
• Modèles de développement qualité
• Méthodes d ’analyse et de conception
• Unification des méthodes objet : UML

coûts délais
9 10

Acteurs d’un projet Conduite de projet

Organisation méthodologique mise en œuvre pour faire en
• Maître d’ouvrage personne physique ou sorte que l’ouvrage réalisé par le maître d’œuvre réponde
aux attentes du maître d’ouvrage dans les contraintes de
morale propriétaire de l’ouvrage. Il détermine délai, coût et qualité.
les objectifs, le budget et les délais de
réalisation. Solutions
Besoins Satisfaction des
Projet Besoins
• Maître d’œuvre personne physique ou
morale qui reçoit mission du maître
d’ouvrage pour assurer la conception et la
réalisation de l’ouvrage. Conduite
de
11 Projet 12
 Conduite de projet Sommaire
Direction de
projet
Synthèse et décisions
• Génie logiciel
Analyse et reporting • Conduite de projet informatique

Gestion des Gestion Gestion des

• Phases de développement
hommes technique Moyens • Modèles de développement
• Méthodes d ’analyse et de conception
Organisation Objectif Planification
Communication Méthode Contrôle • Unification des méthodes objet : UML
Animation Qualité Coûts Délais
Une partie du matériau de ce cours est issue du cours de D. Bardou, UJF, INRIALPES
13 14

Phases de développement Planification

• 7 étapes dans la vie d’un logiciel: • Objectifs : identification de plusieurs solutions et

• Planification (Étude de la faisabilité) évaluation des coûts et bénéfices de chacune
• Spécification des besoins (Requirement analysis) d'elles
• Analyse (Spécification formelle) • Activités : simulation de futurs scénarios de
• Conception (Spécification technique) développement
• Implémentation (Codage)
• Sortie : un schéma directeur contenant
• Tests unitaires
• la définition du problème
• Intégration et tests
• les différentes solutions avec les bénéfices attendus
• Livraison • les ressources requises pour chacune d'elles (délais, livraison,
• Maintenance etc.)

Phases de développement 15 Phases de développement 16

 Spécification des besoins
Spécification des besoins
(suite)

• Objectifs : À partir du cahier des charges, • Activités :

description du problème à traiter
• identification des besoins de l'utilisateur
• spécification du "quoi" fait par le logiciel : informations
manipulées, services rendus, interfaces, contraintes
• Abstraction et séparation des problèmes
• Modularisation : séparation des besoins fonctionnels
• Sorties :
• Modèle conceptuel
• Manuel utilisateur provisoire pour les non
informaticiens
• Plans de tests du système futur (cahier de validation)

Phases de développement 17 Phases de développement 18

Analyse Conception

• Objectifs : • Objectifs :
• Répondre au « Que fait le système ? » • Répondre au « Comment faire le système ?
• modélisation du domaine d ’application • Décomposition modulaire
• analyse de l ’existant et des contraintes de réalisation • Activités :
• Définition de l ’architecture du logiciel
• Activités :
• Définition de chaque constituant du logiciel : informations
• Abstraction et séparation des problèmes traitées, traitements effectués, résultats fournis,
• Sorties : Modèle conceptuel contraintes à respecter
• + dossier de tests d ’intégration • Sorties : Modèle logique
• + dossier de tests unitaires

Phases de développement 19 Phases de développement 20

 Implémentation Tests unitaires

• Objectifs : • Objectifs : test séparé de chacun des

• Réalisation des programmes dans un (des) langage(s) de
programmation composants du logiciel en vue de leur
• Tests selon les plans définis lors de la conception intégration
• Activités :
• Écriture des programmes • Activités :
• Tests • réalisation des tests prévus pour chaque module
• Mise au point (déboguage) • les tests sont à faire par un membre de l'équipe
• Sorties : Modèle physique n'ayant pas participé à la fabrication du module
• Collection de modules implémentés, non testés
• Documentation de programmation qui explique le code • Sorties : Rapport de cohérence logique
Phases de développement 21 Phases de développement 22

Intégration et test du Livraison, maintenance,

système évolution
• Objectifs : • Objectifs :
• Intégration des modules et test de tout le système • Livraison du produit final à l'utilisateur,
• Activités : • Suivi, modifications, améliorations après livraison.
• Assemblage de composants testés séparément • Activités :
• Tests Alpha : l'application est mise dans des conditions réelles • Tests Bêta : distribution du produit sur un groupe de clients
d'utilisation, au sein de l'équipe de développement (simulation avant la version officielle,
de l'utilisateur final)
• Livraison à tous les clients,
• Sorties : • Maintenance : corrective, adaptative, perfective.
• Rapport de conformité • Sorties :
• Démarche d’intégration (ascendante, descendante ou les deux)
• Produit et sa documentation
• Conception des données de tests
• Documentation des éléments logiciels • Trace d’exploitation et d’évolution

Phases de développement 23 Phases de développement 24

 Modèles de développement
Modèles de développement
(suite)
• Objectifs :
• Modèle “code-and-fix”
• Organiser les différentes phases du cycle de vie
pour l'obtention d'un logiciel fiable, adaptable et • Modèle (linéaire) en cascade
efficace
• Guider le développeur dans ses activités • Modèle en V
techniques
• Fournir des moyens pour gérer le • Modèle en spirale
développement et la maintenance (ressources,
délais, avancement, etc.) • ...

Modèles de développement 25 Modèles de développement 26

Modèle en cascade Modèle en V

Expression Validation
Analyse des besoins des besoins

Spécification Validation
Conception
fonctionnelle fonctionnelle

Implémentation Conception Tests du

du système système

Tests
Conception Tests des
des composants composants
Maintenance
Implémentation
Modèles de développement 27 Modèles de développement 28
 Modèle en spirale Sommaire

• Génie logiciel
Analyse
• Conduite de projet informatique
Conception Spécifications
• Phases de développement
• Modèles de développement
• Méthodes d ’analyse et de
Implémentation Validation conception
• Unification des méthodes objet : UML
Tests
Modèles de développement 29 30

Méthode d ’analyse et de De nombreuses méthodes

conception ...
• Proposition d ’une démarche distinguant les étapes • Méthodes fonctionnelles hiérarchiques
du développement dans le cycle de vie du logiciel
• Data-Flow/SADT/SA-SD, Structure-Chart, ...
(modularité, réduction de la complexité,
réutilisabilité éventuelle, abstraction) • Méthodes données
• Utilisation d ’un formalisme de représentation qui • Entité-Relation, MERISE, ...
facilite la communication, l’organisation et la • Méthodes comportements
vérification
• SA-RT, Réseaux de Pétri, ...
• production de documents (modèles) qui facilitent
les retours sur conception et l’évolution des • Méthodes objets
applications • OMT, OOA, Classe-Relation, OOD, ...
Méthodes d’analyse et de conception 31 Méthodes d’analyse et de conception 32
 Unification des méthodes
UML
objet
• Constat : au début des années 90, existe une cinquantaine
de méthodes objet, liées uniquement par un consensus • signifie Unified Modeling Language
autour d ’idées communes (objet, classe, sous-systèmes,
…) MAIS avec chacune sa propre notation, SANS arriver à • est une notation basée sur les méthodes Booch,
remplir tous les besoins et à modéliser correctement les OMT (Rumbaugh), OOSE (Jacobson),
divers domaines d ’application.
• Recherche d ’un langage commun unique
• a été construite afin de standardiser les artéfacts
• utilisable par toute méthode objet, de développement (modèles, notation,
• dans toutes les phases du cycle de vie, diagrammes) SANS standardiser le processus de
• compatible avec les techniques de réalisation actuelles. développement,
Æ UML
• Recherche d’un processus de développement commun, • Rôle important de RATIONAL et de l ’OMG
unique, … ???
Æ Unified Process
Méthodes d’analyse et de conception 33 UML 34

UML (suite) UML (suite)

Points forts des sources Historique
Version béta - fin 99 UML 1.3

• OMT : expressive pour l ’analyse et la Version intermédiaire non publiée UML 1.2

Commentaires du public
conception de systèmes d ’information à Standardisation à l’OMG - Novembre 97 UML 1.1
base de données, Soumission à l’OMG - Janvier 97 UML 1.0

• BOOCH : expressive durant les phases de Juin 96 puis OOPSLA’96 UML 0.9 & 0.91
design et d ’implantation des projets,
OOPSLA’95 Unified Method 0.8
• OOSE : expressive pour l ’analyse des
besoins grâce aux « cas d ’utilisation ». Booch’93 OMT-2

Autres méthodes Booch’91 OMT-1 OOSE Partenaires

UML 35 UML 36
 UML (suite) UML (suite)
Contributions Différentes vues
Booch Rumbaugh Jacobson Vision
OMT
Vision Logique
Booch Method OOSE Implémentation
Meyer
Odell Théorie du contrat
Utilisateus finaux
Vision Programmeurs
Classification Fonctionalités Gestion du logiciel
cas
Harel d’utilisation
Shlaer-Mellor Diagrammes d’états
Cycle de vie des objets Vision Processus Vision Déploiement
Wirfs-Brock
Gamma et al. Responsabilités
Intégrateurs systè me Ingénieur systè me
Topologie du systè me
Frameworks, Embley Fusion Performance
Installation
Changement d’échelles
Patterns, et notes Classes Description de méthodes
Throughput
Communication
singleton Numérotation de message

Conceptuel Physique

UML 37 UML 38

UML (suite) UML (suite)

Différents modèles statique
Différentes vues
modèle : description
complète d’un système Classes, Objets, Composants
selon une perspective State Collaboration, Séquences Vision
State
Diagrams
particulière. Diagrammes
Diagrams
Use Case
Use Case de Classes Vision Logique Implémentation
Diagrams State
Use Case Diagrammes
Diagrams State
Use Case Diagrams
Diagrammes
Diagrams
Diagrammes cas d’utilisation Diagrams
Diagrams Objets Utilisateus finaux Cas d ’utilisation Programmeurs
de Séquences Fonctionalités
Vision Gestion du logiciel

Etats-Transitions cas d’utilisation Déploiement

Scenario State Activité
Scenario
Diagrams State
Diagrams
Diagrammes
Diagrams Modèles Diagrammes
Diagrams
de collaboration de Composants Vision Vision Déploiement
Ingénieur systè me
Processus
Intégrateurs systè me Topologie du systè me
Performance Installation
Scenario Component Changement d’échelles Communication
Scenario
Diagrams
Component
Diagrams
Diagrammes
Diagrammes
Diagrams Diagrams
Etat-transiition de déploiement Conceptuel Physique
Diagrammes
dynamique d’activité
UML 39 UML 40
UML (suite) UML (suite)
Pour en savoir plus ... Pour en savoir plus ...
• The Objectory Software Development
Process Ivar Jacobson, Grady Booch, Jim
Rumbaugh, all of Rational Software Corp.

• Unified Modeling Language Reference

Manual Jim Rumbaugh, Ivar Jacobson,
Grady Booch

• Unified Modeling Language User Guide

Grady Booch, Jim Rumbaugh, Ivar Jacobson
-all of Rational Software Corp.
+ Documentation : http://www.rational.com
41 42