Chapitre I : cadre générale

[2]
 Chapitre I : cadre générale

1. Introduction
La réalisation d’un projet informatique est soumise à des exigences et des principes de génie
logiciel. Il s’agit d’une branche de l’ingénierie associé au développement de logiciels utilisant
des principes, processus et des étapes bien définis à l’aide du système d’information passant
par les étapes de cycle de vie d’un logiciel pour maximiser les chances de la réussite d’un
projet logiciel.

2. Définition du système d’information

Un système d’information est un ensemble organisé de ressources : matériel, logiciel,
personnel, données, procédures qui permettant d’acquérir, de traiter, de stocker des
informations. Chaque entreprise a son propre système d’information qui exprime sa
structure de travail, ce système doit être bien étudié en spécifiant tous les besoins, les
contraintes et les résultats attendus. Pour cela, l’entreprise a besoin d’établir un document
contractuel qui s’appelé « cahier de charge » entre l’utilisateur et le prestataire de service.
Il y a plusieurs méthodes pour assembler les idées et construire notre système d'information
comme méthode MERISE, UML…etc. Pour avoir ces idées sois on va poser des questions à
travers des réunions pour comprendre l'organisation, penser aux problèmes possibles, ou
bien faire des recherches et avoir des documents [01].

3. Cycle de vie d’un logiciel

Le Cycle de vie du développement d’un logiciel est un ensemble d’étapes de la réalisation,
de l’énoncé des besoins à la maintenance au retrait du logiciel sur le marché informatique.
L’objectif principal du cycle de vie d’un logiciel est de permettre la détection des erreurs au
plus tôt et par conséquent, maîtriser la qualité du produit, les délais de sa réalisation et les
coûts associés. Les étapes clés de cycle de vie d’un logiciel sont les suivantes [02] :
Pré-étude : Cette étape permet de définir les objectifs du projet et de définir le domaine
d'activité. Les questions posées sont : quoi ? Combien ?

En entrée on a les besoins et en sortie on a un cahier de charges.

Analyse : Cette étape consiste à recueillir et à formaliser les besoins du client, de définir les
contraintes et d'estimer la faisabilité de ces besoins. La question à poser est : que fait le
système ?

En entrée on a le cahier de charges et en sortie on a le dossier d'analyse.

Conception : Cette étape permet d'élaborer la structure générale du système et de définir

chaque sous-ensemble du logiciel à produire. La question à poser est : comment faire ce
qu'il est demandé de faire ?

En entrée, on a le dossier d'analyse et en sortie on a un dossier de conception.

[3]
 Chapitre I : cadre générale

- Codage : Cette étape consiste à coder ou à programmer les fonctionnalités définis dans la
phase de conception.

En entrée, on a le dossier de conception et en sortie on a des programmes.

Tests : Cette étape permet de tester le logiciel conformément aux spécifications

(fonctionnelle ou non fonctionnelle).

- Réception : Cette étape permet au client de vérifier la conformité du logiciel avec les
spécifications initiales.

En entrée on a un logiciel plus un cahier de charges et en sortie on a un rapport de réception

(acception ou refus du livrable)

- Maintenance : Cette étape permet de prendre en charge les actions collectives du système.

En entrée on a un logiciel et en sortie on a un logiciel modifié.

4. Modèles de cycle de vie d’un logiciel

Les modèles du cycle de vie d’un logiciel sont des « plans de travail » qui permettent de
planifier le développement. Plus le logiciel à développer est complexe (taille,
algorithmes…etc.) et critique, plus il est important de bien contrôler le processus de
développement et plus les documents qui accompagnent le logiciel doivent être précis et
détaillés [02].
Il s’avère de nos jours, que nous ne pouvons plus avoir une démarche unique dans le
développement de projets informatiques, mais qu’il faut construire le découpage temporel
en fonction des caractéristiques de l’entreprise et du projet. On s’appuie pour cela sur des
découpages temporels génériques, appelés modèles de développement ou modèles de cycle
de vie d’un projet informatique. Les principaux modèles sont [02] :

4.1. Modèle en Cascade

C’est un modèle qui considère le développement d’un logiciel comme une succession
d’étapes réalisées de façon strictement séquentielle, chaque étape est validée par un
document et correspond à une activité de base. Le modèle du cycle de vie en Cascade est
souvent adapté quand les besoins de clients sont stables et clairement définis [03].

[4]
 Chapitre I : cadre générale

Figure 01 : le modèle en Cascade.

4.2. Modèle en V
Le modèle en V du cycle de vie du logiciel précise la conception des tests : les tests système
sont préparés à partir de la spécification ; les tests d’intégration sont préparés à partir de la
conception architecturale ; les tests unitaires sont préparés à partir de la conception
détaillée des composants. Dérivé du modèle de la cascade, le modèle en V du cycle de
développement montre non seulement l’enchaînement des phases successives, mais aussi
les relations logiques entre phases plus éloignées. Ce modèle fait apparaître le fait que le
début du processus de développement conditionne ses dernières étapes. Le modèle du cycle
de vie en V est souvent adapté aux projets de taille et de complexité moyenne [02].

Figure 02 : Le modèle en V.
[5]
 Chapitre I : cadre générale

4.3. Cycle de vie en spirale

C’est un modèle itératif, des incréments sous forme de cycle. Chaque cycle donne lieu à une
contractualisation préalable, s’appuyant sur les besoins exprimés lors du cycle précédent.
Chaque cycle est composé des mêmes activités que le modèle en Cascade. Le modèle du
cycle de vie en spirale est souvent adapté quand le prototypage est exigé et les
spécifications ne sont pas stables. Un cycle comporte six phases [02] :

 Analyse du risque.
 Développement d'un prototype.
 Simulation et essais du prototype.
 Détermination des besoins à partir des résultats des essais.
 Validation des besoins par un comité de pilotage.
 Planification du cycle suivant

Figure 03 : cycle de vie en spirale.

[6]
 Chapitre I : cadre générale

4.4. Modèle du cycle de la vie par prototypage

Un modèle de processus basé sur le prototypage se révèle alors plus approprié que le
modèle classique de la cascade. Le prototypage permet de contourner la difficulté de la
validation liée à l’imprécision des besoins et caractéristiques du système à développer. Cela
veut dire que lorsqu’il est difficile d’établir une spécification détaillée, on a recours au
prototypage qui est considéré, dans ce cas, comme un modèle de développement de
logiciels.
Il s’agit d’écrire une première spécification et de réaliser un sous-ensemble du produit
logiciel final. Ce sous ensemble est alors raffiné incrémentalement et évalué jusqu’à obtenir
le produit final [02].

Figure 04 : modèle du cycle de vie par prototypage.

5. Définition de Merise
MERISE est une méthode française née dans les années 70, développée initialement par
Hubert Tardieu. Elle fut ensuite mise en avant dans les années 80, à la demande du ministère
de l'industrie qui souhaitait une méthode de conception des SI.
MERISE est donc une méthode d'analyse et de conception des SI basée sur le principe de la
séparation des données et des traitements. Elle possède un certain nombre de modèles (où
schémas) qui sont répartis sur 4 niveaux [04] :

 Le niveau conceptuel.
 Le niveau organisationnel.
 Le niveau logique.
 Le niveau physique.

[7]
 Chapitre I : cadre générale

La méthode Merise se caractérise par :

 Une approche systémique en ayant une vue de l’entreprise en termes de systèmes.

 La séparation des données (le côté statique) et des traitements (le côté dynamique).
 Une approche par niveaux.

5.1. Niveau conceptuel

Le niveau conceptuel consiste à concevoir le SI en faisant abstraction de toutes les
contraintes techniques ou organisationnelles et cela tant au niveau des données que des
traitements. Le niveau conceptuel répond à la question « quoi ? » [05]
Le formalisme Merise employé sera :

 Le modèle conceptuel des données (MCD).

 Le modèle logique de données (MLD).
 Le modèle conceptuel des traitements (MCT).

5.2. Niveau organisationnel

Le niveau organisationnel a comme mission d’intégrer dans l’analyse les critères liés à
l’organisation étudiée. Le niveau organisationnel fera préciser les notions de temporalité, de
chronologie des opérations, d’unité de lieu...etc. C’est la réponse à la question « qui ?» [05]
Le formalisme Merise employé sera :

 Le modèle organisationnel des données (MOD).

 Le modèle organisationnel des traitements (MOT).

5.3. Niveau logique

Le niveau logique est indépendant du matériel informatique, des langages de
programmation ou de gestion des données. C’est la réponse à la question « avec quoi ?» [05]
Le formalisme sera :

 Le modèle logique des données (MLD).

 Le modèle logique des traitements (MLT).

5.4. Niveau physique

Le niveau physique permet de définir l’organisation réelle (physique) des données. Il apporte
les solutions techniques, par exemple sur les méthodes de stockage et d’accès à
l’information. C’est la réponse à la question « comment ? » [05]
Le formalisme employé sera :
• Le modèle physique des données (MPD).
• Le modèle opérationnel et physique des traitements (MOPT).

[8]
 Chapitre I : cadre générale

Tableau 01 : les modèles de MERISE.

Données Traitements

Niveau conceptuel MCD MCT

Modèle conceptuel de données Modèle conceptuel de
traitements

Niveau organisationnel MOD MOT

Modèle organisationnel de Modèle organisationnel de
données traitements

Niveau logique MLD MLT

Modèle logique de données Modèle logique de
traitements

Niveau physique MPD MPT

Modèle physique de données Modèle physique de
traitements

6. Langage UML
L’acronyme UML signifie Unified Modeling Langage, soit « Langage Unifié de Modélisation »,
est un langage de modélisation très complet qui couvre de nombreux aspects du
développement des logiciels, comme les exigences, l’architecture, les structures et les
comportements.
La modélisation proposée par le langage UML se réalise principalement sous forme
graphique, en usant de divers types de diagrammes spécifiques pour représenter le logiciel à
développer.
Depuis sa normalisation, en 1997, UML a fortement évolué passant d’un langage peu formel,
principalement destiné à la documentation, à un langage suffisamment précis pour que des
applications puissent être générées à partir des modèles.
Au final, le langage UML est une synthèse de tous les concepts et formalismes
méthodologique les plus utilisés, grâce à sa simplicité et à son universalité, comme langage
de modélisation pour la plupart des systèmes devant être développés [06].
Les diagrammes les plus utilisés sont :

[9]
 Chapitre I : cadre générale

Figure 05 : les types des diagrammes d’UML.

6.1. Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation décrit les fonctionnalités d’un point de vue d’utilisateur,
sous forme d’action et de réactions ; l’ensemble des fonctionnalités est déterminé en
examinant les besoins fonctionnels de tous les utilisateurs potentiels.
Le but de ce diagramme est d’identifier les catégories d’utilisateurs : chacune d’entre elles,
appelée acteur, est susceptible de mettre en œuvre une ou plusieurs fonctionnalités du
système. Ainsi que les besoins du système : chaque fonctionnalités, appelée cas d’utilisation,
doit répondre à l’un des besoins nécessités par une ou plusieurs catégories d’utilisateurs. Par
conséquent, les résultats de cette étude en faisant apparaitre tous les acteurs, tous les cas
d’utilisation, et les relations entre ces divers éléments [06].

6.2. Diagramme de séquence

Les diagrammes de séquence décrivent le déroulement de chaque cas d’utilisation, en
montrant la façon dont les diverses entités mises en œuvre dans les cas d’utilisation
interagissent et collaborent dans le temps afin de réaliser les fonctionnalités attendues. Le
but ce diagramme est de déterminer les divers entités, appelées objets, mises en jeu dans la
réalisation d’une fonctionnalité, ainsi que les interactions entre ces divers objets et le
déroulement dans le temps de ces interactions.
Typiquement, chaque cas d’utilisation détermine dans le diagramme des cas d’utilisation fait
l’objet d’une étude temporelle des interactions en utilisant un diagramme de séquence. Par
conséquent, on doit avoir autant de diagrammes de séquence que de cas d’utilisation ;
occasionnellement, un cas d’utilisation peut être décrit par plusieurs diagrammes de
séquence afin de clarifier l’ensemble [06].

[10]
 Chapitre I : cadre générale

6.3. Diagramme de classe

Le diagramme de classe représente, de manière statique, les classes qui composent le
système, ainsi que les relations existent entre elle. Le but de ce diagramme est de d’écrire la
structure statique interne précise de chacune des classes (attributs et méthodes), ainsi que
les relations entre les classes mises en œuvre.
Le diagramme de classe se construit en partie à l’aide des informations issues des diffèrent
diagrammes de séquence. Il permet d’obtenir le squelette du code par génération
automatique du code. Il s’agit donc de la dernière étape d’analyse juste avant le codage
proprement dit. Par conséquent, il fait partie de la conception détaillée du système [07].

6.4. Diagramme d’activité

Un diagramme d’activité expose les activités séquentielles et parallèles d’un processus. Le
diagramme montre à la fois le flot de de contrôle et le flot de données, une transition est
déclenchée automatiquement une fois l’action terminée.
Les diagrammes d'activité sont des graphes, avec différents types de nœuds et d'arcs. Ils
sont utilisés pour représenter le déroulement de processus métier, des enchainements
d’activités regroupées séquentiellement et les synchronisations d’activités [07].

7. UML VS Merise
Le tableau 2 représente une comparaison entre Merise et UML.
Tableau 02 : Comparaison entre Merise et UML.

Merise UML

Outils de modélisation Méthode d’étude et de Unified Modeling Language

réalisation informatique pour les
systèmes d’entreprise.

Organisme Franco-français International

Approche Merise est une méthode
systémique d’analyse et de
conception des systèmes
d’informations ; elle utilise une
approche systémique.
UML n’est pas une méthode
mais plutôt un langage de
modélisation objet à qui il
faut associer une démarche
pour en faire une méthode.

Etude Merise propose de considérer le Avec UML centraliser les

système réel selon deux points
de vue :
-une vue statique (données).
-une vue dynamique
données d’un type et les
traitements associés permet
de limiter les points de
maintenance dans le code et
faciliter l’accès à
l’information en cas

[11]
 Chapitre I : cadre générale

(traitements). d’évolution du logiciel.

C’est-à-dire nous avons une UML décrit la dynamique du

étude séparée des données et SI comme un ensemble
des traitements. d’opération attachée aux
objets du système.

Base de données Relationnel Orienté objet

8. Conclusion
Dans ce chapitre nous présentant quelque notion de base de l’ingénierie logiciel. Ce travail a
été effectué avant le début du projet pour clarifier notre besoin. A ce fait nous adoptons le
modèle de cycle de vie en Cascade car nos besoins sont clairement définis, nous adoptons
l’approche orientée objet pour modéliser notre système en se basant sur les diagrammes
d’UML parce qu’ils nous aident à bien déterminer notre système et ses fonctionnalités.

[12]