Chapitre 1

Introduction

1
LE LOGICIEL
  Un logiciel ou une application est un ensemble de
programmes, qui permet à un ordinateur ou à un système
informatique d'assurer une tâche ou une fonction en
particulier (exemple : logiciel de comptabilité, logiciel de
gestion des prêts).
  Les logiciels, suivant leur taille peuvent :
  être développés par une personne seule, une petite équipe, ou
un ensemble d'équipes coordonnées.
  le développement de grands logiciels par de grandes équipes
pose d'importants problèmes de conception et de
coordination.

2
2
Le Génie Logiciel
  Le génie logiciel est un domaine de recherche qui a été
défini du 7 au 11 octobre 1968,
  Il a pour objectif de répondre à un problème qui
s'énonçait en deux constatations : d'une part le logiciel
n'était pas fiable, d'autre part, il était incroyablement
difficile de réaliser dans des délais prévus des logiciels
satisfaisant leur cahier des charges.

3
3
Le Génie Logiciel
  L'objectif du génie logiciel est d'optimiser le coût de
développement du logiciel. L'importance d'une approche
méthodologique s'est imposée à la suite de la crise de
l'industrie du logiciel à la fin des années 1970. Cette crise
de l'industrie du logiciel était principalement due à :
  l'augmentation des coûts ;
  les difficultés de maintenance et d'évolution ;
  la non-fiabilité ;
  le non-respect des spécifications ;
  le non-respect des délais.

4
4
Le Génie Logiciel
  Pour apporter une réponse à tous ces problèmes, le génie
logiciel s'intéresse particulièrement à la manière dont le
code source d'un logiciel est spécifié puis produit. Ainsi, le
génie logiciel touche au cycle de vie des logiciels :
  l'analyse du besoin,
  l'élaboration des spécifications,
  la conceptualisation,
  le développement,
  la phase de test,
  la maintenance.

5
5
Pourquoi et comment modéliser
  Qu’est ce qu’un modèle : Un modèle est une
représentation abstraite et simplifiée (i.e. qui exclut
certains détails), d'une entité (phénomène, processus,
système, etc.) du monde réel en vue de le décrire, de
l'expliquer ou de le prévoir.
  Modèle est synonyme de théorie, mais avec une
connotation pratique : un modèle, c'est une théorie
orientée vers l'action qu'elle doit servir.

6
6
Pourquoi et comment modéliser
  Concrètement, un modèle permet de réduire la
complexité d'un phénomène en éliminant les détails qui
n'influencent pas son comportement de manière
significative.
  Il reflète ce que le concepteur croit important pour la
compréhension et la prédiction du phénomène modélisé.
Les limites du phénomène modélisé dépendant des
objectifs du modèle.

7
7
Pourquoi et comment modéliser :
Exemples de modèles
  Modèle météorologique : à partir de données
d'observation (satellite…), il permet de prévoir les
conditions climatiques pour les jours à venir.
  Modèle économique : peut par exemple permettre de
simuler l'évolution de cours boursiers en fonction
d'hypothèses macro-économiques (évolution du
chômage, taux de croissance…).
  Modèle démographique : définit la composition d'un panel
d'une population et son comportement, dans le but de
fiabiliser des études statistiques, d'augmenter l'impact de
démarches commerciales, etc.

8
8
Pourquoi et comment modéliser :
Exemples de modèles
  Plans : Les plans sont des modèles qui donnent une vue
d'ensemble du système concerné. Par exemple, dans le
bâtiment, pour la construction d'un immeuble, il faut
préalablement élaborer de nombreux plans :
  plans d'implantation du bâtiment dans son environnement ;
  plans généraux du bâtiment et de sa structure ;
  plans détaillés des différents locaux, bureaux, appartements…
  plans des câblages électriques ;
  plans d'écoulements des eaux, etc.

9
9
Un seul système … plusieurs points de
vue

10
10
Informatique : Naissance du besoin de
modéliser
  Un modèle :
- est une abstraction du réel à informatiser.
- utilise un ensemble de concepts et un ensemble de règles
d’utilisation :
- Les concepts fournissent le moyen de représenter
les entités du monde réel et les relations qui existent
entre elles.
- Les règles sont définies sur les concepts du modèle
et régularisent leurs utilisations.
Remarque:
Pour assister le concepteur afin d’élaborer le(s) modèle(s) on
a besoin d’une méthode.

11
11
Naissance du besoin de modéliser
  Une méthode :
- Guide la transition du réel à sa perception et de cette
dernière vers l’implantation.
- Composée de :
+ Un ensemble d’étapes successives : une démarche.
+ Un ensemble de modèles exprimant des points de vue
différents.
+ Un ensemble de concepts (et leurs règles d’utilisation)
permettant la représentation de ces modèles.

12
12
Pourquoi une méthodologie /
Processus?
  L'organisation des tâches n'est pas contenue dans les
techniques
  Elle doit être décrite à un plus haut niveau d'abstraction

13
13
Pourquoi utiliser une méthodologie /
Processus?
  De nombreux avantages sont avancés
  Aide à produire un produit de meilleure qualité
  Logiciel mieux documenté
  Plus acceptable par l'utilisateur
  Plus facile à maintenir/entretenir
  Logiciel plus homogène
  Aide à assurer que les spécifications des utilisateurs sont
suivies
  Aide le manager du projet à contrôler le projet
  Réduit les coûts de développement
  Encourage la communication entre les personnes

14
14
Evolution des méthodes de conduite
de projet

15
 Approches Classiques dites
Séquentielles
  Toutes s’intersectent dans les étapes suivantes :

Analy. & définition

des besoins Conception Exploitation
&
Réalisation Maintenance
Tests

16
 Approches Classiques dites
Séquentielles
  Toutes s’intersectent dans les étapes suivantes :

Analy. & définition

des besoins Conception Exploitation
&
Réalisation Maintenance
Tests

  ne sont pas forcément appelées de la même manière par toutes les

méthodes

  Avec les tests, deux étapes peuvent exister :

1. la vérification du système : « Est-ce que nous construisons bien le système ? »
2. la validation du système : « Est-ce que nous construisons le bon système ? »

17
Activités des méthodes de conduite de
projets
  Analyse et définition des besoins : Etude du métier du
client, étude des besoins des utilisateurs, formulation du
CDC sous une forme exploitable en conception
  Conception : Définition de l’architecture logicielle,
définition du comportement de l’application
  Réalisation : Implémentation
  Tests
  Exploitation et maintenance

18
18
Analyse des besoins
  L'analyse des besoins définit les services du système,
ses contraintes et ses buts, en consultant les utilisateurs
du système. Une étude d'opportunité peut être menée
pour savoir si le système est réalisable et donner une
approximation de la rentabilité de ce système.
  Synonymes : analyse préalable, user requirements analysis.

19
19
Analyse
  l'analyse est la construction d'un modèle (une
spécification) du système à partir de l'analyse des besoins.
À partir de ce modèle on peut proposer plusieurs
scénarii et réaliser une étude de faisabilité.
  Synonymes : spécification des besoins, analyse préalable,
  analysis, user requirement specification, requirements
engineering.

20
20
Conception
  la conception est une proposition de solution au
problème spécifié dans l'analyse.
  Définit la solution retenue par prise en compte des
caractéristiques logiques d'usage du futur système
d'information et des moyens de réalisation, humains,
techniques et organisationnels.
  On distingue souvent :
  la conception système : a pour objectif de donner
l'architecture globale du systèmes (i.e. les différentes
parties)
  la conception détaillée : décrit chaque partie du système.

21
21
Réalisation et tests
  La réalisation et le test produisent la solution
exécutable en termes de programmes.
  Pour les logiciels complexes, on distingue l'implantation
des différentes parties et leur validation par des tests
unitaires et l'implantation du système complet par
intégration des parties et tests systèmes.
  On vérifie ainsi que les spécifications des besoins sont
satisfaites.

22
22
 Processus en cascades
  Schématiquement :

23
Processus en V

Analyse des besoins Installation et

et de la faisabilité Test système

Test
Spécification des Besoins
d’acceptation

Conception Intégration et tests

Architecturale d’intégration

Conception
Test unitaire
détaillée

Programmation

24
Le projet n’est pas uniquement du Code

25
25
Modéliser
  Objectif principal de la modélisation = maitriser la
complexité
  Modéliser = abstraire la réalité pour mieux comprendre
le système à réaliser / réalisé
  Le modèle doit être relié au monde réel
  Par exemple : l’existant avant les travaux, le réalisé, le restant à
réaliser
  Un modèle peut être exprimé avec différents niveaux
d’abstraction / raffinement
  Par analogie : répartition électrique de l’immeuble, de la
cage d’escalier, de l’appartement, de la pièce
  Une seule “vue” du système n’est pas suffisante
26
26
Comment modéliser en O.O?
 Orienté objet = abstraire et décomposer le système
informatique en objets
♦ Le monde réel est constitué d’objets physiques ou
immatériels
♦ Tracer les objets virtuels de modélisation depuis les
objets du monde réel
▶ Relier les objets (réels) du problème et les objets
(virtuels) de la solution
♦ Favoriser les abstractions naturelles du monde réel
utilisables en modélisation
▶ Objets vus comme des “boites noires”: seules les
propriétés visibles de l’extérieur intéressent
27
▶ Objets possédant un nom, qualifiables, classables, 27
Unified Modeling Language (UML)

28
28
UML … Un Langage
  UML est un langage de modélisation orienté objet
  UML n’est pas une méthode
  UML a été adopté par toutes les méthodes orientées
objet
  UML est dans le domaine public ; c’est un standard
  UML est un langage pour :
♦ Visualiser : Chaque symbole graphique possède une
sémantique
♦ Spécifier : De manière précise et complète, sans
ambiguïté
♦ Construire : Une partie du code des classes peut êre
généreé automatiquement
29
29
UML n'est qu'un langage
  Bien qu’issu d’une concertation visant à produire le
processus Unifié, UML n'est qu'un langage de modélisation
et non une méthodologie à part entière.
  UML définit des notations utiles dans toutes les étapes du
développement d'un logiciel, de l'analyse des besoins à la
livraison de celui-ci, mais il ne propose aucune démarche
spécifique pour mener ce développement à terme.
  En ce sens, UML peut a priori être utilisé dans le cadre de
l'utilisation de toute méthode de développements (par
objets).

30
30
Pourquoi une méthodologie /
Processus?
  Les techniques (diagrammes d’UML) de développement
de système doivent être organisées si elles doivent
fonctionner ensemble

  UML même ne contient rien qui aide à prendre cette

décision

31
31
Diagrammes d’UML

32
32
Axes de modélisation d’un système

33
33
 Diagrammes UML
Cas d’utilisation
Composants
Objets

Classes Vue logique statique Vue Implémentation

(Structure des objets) (composants logiciels)

Vue externe
(fonctions système)
Séquence Vue déploiement
Vue logique dynamique
(Environnement
(Comportement)
d’implantation)
Collaboration

Activités
États transitions Déploiement

34
34
35
35