République Algérienne Démocratique et Populaire

Ministère de l’enseignement Supérieur et de la Recherche Scientifique

Université de Mohamed El Bachir El Ibrahimi de Borj Bou Arréridj
Faculté des Mathématiques et d’Informatique
Département d’informatique

Mémoire
Présenté en vue de l’obtention du diplôme

Licence en Informatique

Titre
Conception et réalisation d’un jeu de
Quiz sous Android

Présenté Par

Imene NOUIOUA et Ratiba NOUIOUA

Soutenu le ...
Devant le jury composé de :
Président ... ...
Encadrant Nadjib BENAOUDA MCB, Université de BBA
Examinateur ... ...

Promotion 2021-2022
Dédicaces

Nous tenons à dédier cet humble travail comme preuve de respect, de gratitude et de recon-
naissance :
A nos chères parents, nos frères, nos sœurs et amies
Pour leurs encouragements, soutiens, patiences et prières.

i
Remerciements

C’est avec un immense plaisir que je réserve ces quelques lignes en signe de gratitude et
de reconnaissance à tous ceux qui ont contribué de près ou de loin à l’élaboration de ce tra-
vail. Nous rendons grand merci à Dieu Tout-Puissant qui nous a donné une grande volonté et
suffisamment de connaissances pour faire cet humble travail.
À notre encadrant Dr. Nadjib Benaouda pour sa compréhension, sa disponibilité, son aide
et ses précieux conseils qui nous ont été très utiles pour l’achèvement de ce projet.
Nos remerciements s’étendent à tous nos enseignants du département d’Informatique de
l’Université BBA, en particulier à Dr. Nouioua Farid pour son aide et ses orientations.
Nous tenons à remercier aussi Dr. Nouioua Mourad pour son aide et ses conseils.
Enfin, Merci à toutes les personnes qui ont contribué de près ou de loin à l’accomplissement
de ce travail.

ii
Résumé

Dans ce projet de fin d’études, nous avons créé une application mobile de jeu quiz dans
laquelle chaque utilisateur peut en profiter et en bénéficier grâce à l’énorme quantité d’infor-
mations culturelles fournies par l’application. Nous avons suivi une démarche d’analyse et de
conception rigoureuse en commençant par l’analyse et l’expression des besoins de l’application
aussi bien fonctionnels que non fonctionnels. Ensuite, nous avons utilisé le langage de modélisa-
tion objet UML pour la conception de l’application à l’aide de différents types de diagrammes.
Enfin, nous avons réalisé notre application à l’aide de l’IDE Android studio et en faisant
appel à diverses technologies telles que : Android studio, Java, SQLite, etc. Nous espérons que
cette application sera amusante et ludique mais aussi utile pour l’enrichissement du bagage
culturel de son utilisateur à travers la variété des informations qu’elle peut offrir.

iii
Abstract

In this graduation project, we have created a quiz game mobile application in which every
user can enjoy and benefit from the huge amount of cultural information provided by the ap-
plication. We followed a rigorous analysis and design process, starting with the analysis and
expression of the application’s needs, both functional and non-functional. Next, we used the
UML object modeling language for designing the application using different types of diagrams.
Finally, we created our application using the Android studio IDE and using various techno-
logies such as : Android studio, Java, SQLite, etc. We hope that this application will be fun and
playful but also useful for enriching the cultural background of its user through the variety of
information it can offer.

iv
Table des matières

Dédicaces i

Remerciements ii

Résumé iii

Abstract iv

Introduction générale 1

1 Expression des besoins 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du domaine d’étude . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Les applications mobiles . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Objectives des applications mobiles . . . . . . . . . . . . . . . . . . . 4
1.2.3 Les jeux de Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Buts visés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Utilisateurs visés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Modélisation UML 8
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

v
2.2 Notions de modèle et de modélisation . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Qu’est-ce qu’un modèle ? . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 C’est quoi une modélisation ? . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Les trois vues principales de modélisation d’un logiciel . . . . . . . . 9
2.2.3.1 Vue fonctionnelle : . . . . . . . . . . . . . . . . . . . . 10
2.2.3.2 Vue statique : . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3.3 Vue dynamique : . . . . . . . . . . . . . . . . . . . . . 10
2.3 Qu’est-ce que le langage UML ? . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Vue fonctionnelle : diagramme de cas d’utilisation . . . . . . . . . . . . . . . 11
2.4.1 Qu’est-ce qu’un diagramme de cas d’utilisation ? . . . . . . . . . . . . 11
2.4.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 Les cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.4 Notre diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . 12
2.4.5 La spécification détaillée des cas d’utilisation . . . . . . . . . . . . . . 12
2.4.5.1 Cas d’utilisation : Jouer . . . . . . . . . . . . . . . . . . . . 13
2.4.5.2 Cas d’utilisation : Consommer indice . . . . . . . . . . . . . 14
2.4.5.3 Cas d’utilisation : Consommer bonus 50 :50 . . . . . . . . . 14
2.4.5.4 Cas d’utilisation : Regarder vidéo publicitaire . . . . . . . . 15
2.5 Vue statique : diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 Qu’est-ce qu’un diagramme de classes ? . . . . . . . . . . . . . . . . . 15
2.5.2 Notre diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Vue dynamique : diagramme de séquence . . . . . . . . . . . . . . . . . . . . 17
2.6.1 Qu’est-ce qu’un diagramme de séquence ? . . . . . . . . . . . . . . . . 17
2.6.2 Nos diagrammes de séquence système . . . . . . . . . . . . . . . . . 18
2.6.2.1 Cas d’utilisation : Jouer . . . . . . . . . . . . . . . . . . . . 18
2.6.2.2 Cas d’utilisation : Choisir niveau . . . . . . . . . . . . . . . 19
2.6.2.3 Cas d’utilisation : Choisir question . . . . . . . . . . . . . . 19
2.6.2.4 Cas d’utilisation : Répondre à la question . . . . . . . . . . . 20
2.6.2.5 Cas d’utilisation : Consommer indice . . . . . . . . . . . . . 21
2.6.2.6 Cas d’utilisation : Consommer un bonus 50/50 . . . . . . . . 21
2.6.2.7 Cas d’utilisation : Regarder vidéo publicitaire . . . . . . . . 22
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

vi
3 Réalisation 23
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Présentation d’Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Android Studio comme IDE . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 Le Kit de développement (SDK) d’Android . . . . . . . . . . . . . . . 24
3.3.3 Le langage Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.4 SQLite : système de gestion de bases de données relationnelles . . . . . 25
3.4 Présentation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.2 Liste des niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.3 Liste des questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4.4 Interface propre aux détails d’une question à choix multiples . . . . . . 28
3.4.5 Interface propre aux détails d’une question Vrai/Faux . . . . . . . . . . 28
3.4.6 Épuisement des vies et des bonus . . . . . . . . . . . . . . . . . . . . 29
3.4.7 Consommation de bonus . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.8 Interface d’obtention davantage de vies et de bonus . . . . . . . . . . 30
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Conclusion générale 31

Bibliographie 32

vii
Table des figures

2.1 Les trois vues essentielles d’un logiciel. . . . . . . . . . . . . . . . . . . . . . 9

2.2 Notre diagramme de cas d’utilisation. . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Diagramme de classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Notre diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Diagramme de séquence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Diagramme de séquence système du cas : Jouer. . . . . . . . . . . . . . . . . 18
2.7 Diagramme de séquence système du cas : Choisir niveau. . . . . . . . . . . . . 19
2.8 Diagramme de séquence système du cas : Choisir question. . . . . . . . . . . . 19
2.9 Diagramme de séquence système du cas : Réponde à la question. . . . . . . . . 20
2.10 Diagramme de séquence système du cas : Consommer indice. . . . . . . . . . . 21
2.11 Diagramme de séquence système du cas : Consommer bonus 50 :50. . . . . . . 21
2.12 Diagramme de séquence système du cas : Regarder vidéo publicitaire. . . . . . 22

3.1 Interface d’accueil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Listes des niveaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Liste des questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Interface propre aux détails d’une question à choix multiples. . . . . . . . . . 28
3.5 Interface propre aux détails d’une question Vrai/Faux. . . . . . . . . . . . . . 28
3.6 La consommation des bonus. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7 La consommation des bonus. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 Interface d’obtention davantage de vies et de bonus. . . . . . . . . . . . . . . 30

viii
Liste des tableaux

2.1 Description textuelle du cas d’utilisation : Jouer. . . . . . . . . . . . . . . . . 13

2.3 Description textuelle du cas d’utilisation : Consommer indice. . . . . . . . . . 14
2.4 Description textuelle du cas d’utilisation : Consommer bonus 50 :50. . . . . . . 14
2.5 Description textuelle du cas d’utilisation : Regarder vidéo publicitaire. . . . . . 15

ix
Introduction générale

Le monde connaît une innovation et un développement technologiques exponentiels, surtout

après l’émergence de l’informatique mobile, qui est la technologie utilisée pour transmettre
la voix et les données via de petits appareils portables utilisant des réseaux sans fil. Dans ce
contexte, les applications informatiques mobiles d’aujourd’hui sont omniprésentes et réparties
dans les activités commerciales, grand public, industrielles, de divertissement et bien d’autres
activités spécialisées. Un appareil informatique portable est l’appareil préféré de presque tous
les utilisateurs. Le principal avantage de l’informatique mobile est la commodité, qui permet
aux utilisateurs d’accéder aux informations et aux ressources informatiques à tout moment et
n’importe où. Parmi les applications utilisées aujourd’hui, les jeux connaissent un développe-
ment important. Pour cela, nous nous intéressons dans ce mémoire au développement d’une
application mobile mettant en œuvre un jeux de Quiz.
Le jeu de Quiz est parmi les jeux les plus populaires qu’on trouve souvent installés sur les
smartphones ou les tablettes. Il consiste en un questionnaire permettant de tester des connais-
sances générales ou spécifiques. Son intérêt est qu’il permet le développement de l’intelligence
et des capacités mentales, la formation et la résolution de problèmes ainsi que la fourniture
d’une énorme quantité d’informations culturelles.
Notre objectif est de créer une application qui soit à la fois amusante et utile en nous per-
mettant d’enrichir notre culture générale. Dans notre application, lorsque le joueur appuie sur
le bouton joueur pour passer à la liste des niveaux, il choisit le premier niveau ouvert, tandis
que le autres niveaux reste fermés. Ensuite, le joueur choisit l’une des questions (Vrai/faux ,
Choix multiple) disponibles. S’il ne peut pas répondre à la question, il peut choisir l’un des
outils d’aide. De plus, une fois qu’il puisse collecter assez de vies, il peut continuer à jouer en
ouvrant le deuxième niveau et ainsi de suite. Tout au long de ce mémoire, nous allons présen-

1
ter l’essentiel des étapes suivis durant la réalisation de notre projet. Ces étapes sont décrites à
travers les trois chapitres suivants :
Le chapitre 1 présente la première étape de notre travail dans laquelle nous avons collecté
les informations essentielles nécessaires au développement de l’application. Pour cela, nous
avons déterminé le domaine d’étude qui est le sujet de ce mémoire, les buts et les personnes
visées par cette application. Ainsi, nous allons spécifier et décrire les besoins fonctionnels et
non fonctionnels de notre application, tout cela dans le cadre de l’expression des besoins de
cette dernière.
Dans le chapitre 2, nous allons nous intéresser à l’analyse et à la conception de l’application,
et cela en définissant quelques notions liées à la modélisation. Pour cela , nous nous baserons
sur le langage de modélisation UML, qui se démarque par une flexibilité marquante, et qui se
caractérise par l’utilisation de différents types de diagrammes.
Enfin, dans le chapitre3 qui est le dernier chapitre, Nous ferons preuve de concrétisation des
notions déjà vus dans le 2ème chapitre, et cela dans le cadre d’une application qui implémente et
met en œuvre toutes ces notions. Le résultat obtenu sera donc un produit final, qui peut être ex-
ploité par les utilisateurs. Pour mener à bien l’implémentation de notre application, nous avons
fait appel à un ensemble d’outils, de langages de programmation et de techniques que nous al-
lons présenter brièvement dans ce mémoire et montrer leurs usages lors du développement de
l’application.

2
Chapitre 1
Expression des besoins

1.1 Introduction
Dans ce chapitre, nous décrivons notre projet qui consiste à créer une application mobile
d’un jeu destiné à être l’utilisé en temps libre. L’application proposée est un jeu de divertisse-
ment dans lequel l’utilisateur répond à des questions qui sont classifiées sous plusieurs domaines
comme : science, religion, médecine, sport, culture générale, etc. Cette application nous offre
plusieurs avantages, notamment le développement de l’intelligence et la précision des informa-
tions culturelles des utilisateurs, l’amélioration des capacités cognitives dont nous avons besoin
dans notre vie.

1.2 Présentation du domaine d’étude

L’informatique est la technologie la plus utilisée actuellement pour proposer des solutions à
nos problèmes quotidiens. En fait, l’informatique est omniprésente dans de multiples secteurs
et permet aujourd’hui d’accomplir des tâches complexes dans plusieurs domaines et les solu-
tions offertes sont en fort développement de jour en jour. Le domaine de développement des
applications mobiles est notamment l’un de ces domaines intéressants qui connaît une activité
intense depuis plusieurs années.

1.2.1 Les applications mobiles

Une application mobile est un programme informatique téléchargeable de façon gratuite

ou payante sur Internet. Une application mobile est exécutée dans un système d’exploitation

3
d’un dispositif mobile comme : PDA, smartphones, tablettes. . . etc. La majorité des applica-
tions mobiles sont distribuées sur des plateformes de téléchargement telles que la plateforme
d’Apple (App Store), la plateforme de Google Android (Google Play) ou encore la plateforme
de Microsoft Windows (Windows Phone Store).

1.2.2 Objectives des applications mobiles

Une application mobile est développée et utilisée pour plusieurs objectifs comme : l’utilisa-
tion d’un service déjà existant, la communication, la recherche des informations, l’échange des
informations . . . etc. Actuellement, il existe une très large diversité des applications mobiles :
réseaux sociaux, OPS, Boîte E-mail, jeux . . . etc. Un jeu mobile est un jeu qui fonctionne sur un
appareil mobile comme les smartphones ou les tablettes tactiles.
Le premier jeu qui a été créé sur un téléphone mobile était une version de Tetris sur le
HAGENUR MT 2000 en 1994. Avec le développement scientifique et les avancées des techno-
logies modernes, divers jeux sont apparus et classifiées sous plusieurs catégories : jeux d’action,
jeu d’aventure, jeu éducatif, jeu de sport, simulation et culture générale.

1.2.3 Les jeux de Quiz

Le jeu de Quiz est parmi les jeux les plus populaires qu’on trouve souvent installés sur les
smartphones ou les tablettes. Il consiste en un questionnaire permettant de tester des connais-
sances générales ou spécifiques ainsi que les compétences des utilisateurs dans un sujet donné.
Le Quiz visé doit obéir complètement ou partiellement aux directives suivantes :
• La diversité des questions qui doit englober beaucoup de catégories comme : la science,
l’histoire, le sport. . . etc.
• Le jeu propose plusieurs niveaux avec un certain nombre de questions pour chaque niveau.
• Le joueur commence le jeu à partir d’un niveau initial et débloque d’autres niveaux dès
qu’il arrive à un certain score donné.
• Au minimum, deux types de questions doivent être considérés, à savoir les questions à
choix multiple et les questions de type vrai ou faux.
• Pour chaque question, le joueur peut bénéficier d’une aide en lui limitant le nombre des
choix possibles pour répondre (50/50) ou en lui proposant un indice sur la réponse.
• Des détails sur cette réponse peuvent également être visualisés à chaque réponse positive
permettant ainsi une meilleure appréhension des réponses données.

4
 • Le nombre d’opportunités à jouer (le nombre d’essais autorisés ou le nombre de vies) peut-
être initialement limité et puis diminué à chaque mauvaise réponse. Ainsi, le joueur ne peut plus
jouer s’il atteint le nombre d’essais autorisés. Autrement dit, si le nombre de vies est égale à
zéro.
• Le jeu est proposé uniquement pour le mode mono-joueur.

1.3 Buts visés

Les jeux électroniques ont un grand impact sur la culture des individus en général en rai-
son de leur large diffusion. Les jeux électroniques à des fin éducatives sont conçus d’une façon
réactive et agréable pour être utilisés par les utilisateurs en temps libre. Ils permettent aux utili-
sateurs, non seulement de tirer profit intelligemment de leur temps libre, mais aussi de :
• Développer leurs créativités eu leurs pensées.
• Encourager la lecture et la recherche des informations.
• Maintenir l’attention et la concentration.
• Amélioration des capacités cognitives et mentales.
• Avoir un moyen de se rapprocher des concepts et de prendre conscience du sens des choses.
• Développer les différents aspects cognitifs.
• Cultiver un intérêt croissant pour la technologie.

1.4 Utilisateurs visés

le jeu développé est destiné à toute personne instruite qui souhaite profiter de son temps libre
pour enrichie ces connaissances et élargir sa culture généralr de façon agréable et conviviale.

1.5 Spécification des besoins

La spécification des besoins est un document qui décrit les caractéristiques et le comporte-
ment d’un système ou d’une application, y compris une variété d’éléments. Il tente de définir la
fonctionnalité prévue et souhaité du système.
Dans cette section, on distingue deux sortes de besoins : besoins fonctionnelles et besoins
non-fonctionnelles.

5
1.5.1 Besoins fonctionnels

Les besoins fonctionnels expriment une action qu’on doit effectuer dans le système en ré-
pondant à une demande (ensemble de sorties qui sont produites en fonction d’un ensemble
d’entrées). Les principales fonctions de notre système sont les suivantes :
• La possibilité de sélection et de déblocage des niveaux à base du score obtenu.
• Dans chaque niveau, l’application doit proposer un certain nombre de questions connexes
aux différentes catégories envisagées et parmi lesquelles l’utilisateur peut choisir.
• Pour chaque question, l’application doit proposer deux formes d’aide : soit une aide par
indice, soit une limitation du nombre de suggestions possibles dans le cas d’une question à
choix multiple
• Des commentaires sur la réponse doivent être présentés à chaque bonne réponse sur une
question.
• Se souvenir de l’état de chaque question (résolue ou non).
• La mise à jouer du score obtenu à chaque bonne réponse.
• La décrémentation du nombre de vies possibles à chaque mauvaise réponse. La même
chose pour le nombre d’aides qui doit être décrémenté à chaque consommation d’un outil
d’aide.
• La possibilité d’acheter des vies et des aides supplémentaires.

1.5.2 Besoins non fonctionnels

Il s’agit des besoins qui caractérisent le système. Ce sont des besoins en matière de per-
formance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les
contraintes d’implémentation (langage de programmation, type de SGBD, système d’exploita-
tion. . . etc.).
En ce qui concerne notre application, nous avons dégagé les besoins suivants :
• La proposition de l’application en deux langues : Arabe et français.
• La prise en charge de différentes dimensions d’écrans.

6
1.6 Conclusion
Dans ce premier chapitre, nous avons introduit le contexte général de notre projet et nous
avons exprimé les principaux besoins de notre application.
Nous avons présenté notre domaine d’étude, les buts et les utilisateurs visés. Ensuite, nous
avons introduit la spécification des besoins de l’application. Plus précisément, nous avons dis-
tingué antre les besoins fonctionnels et non-fonctionnels.Le chapitre suivant de notre projet est
consacré à l’analyse et la conception de notre application.

7
Chapitre 2
Modélisation UML

2.1 Introduction
Dans ce chapitre, nous nous intéressons à la deuxième étape de notre travail qui consiste
en l’analyse et la conception de notre application mobile, et cela à l’aide du langage de modé-
lisation UML. Ce dernier comporte les principaux modèles propres à notre système et utilise
différents types de diagrammes. Nous nous limitons aux trois diagrammes suivants qui sont
pertinents et suffisants pour modéliser notre application :

• Diagramme de cas d’utilisation.

• Diagramme de classes.

• Diagramme de séquence.

Ce chapitre résume l’essentiel de cette deuxième étape en mettant l’accent sur les points sui-
vants :

• Les deux notions de modèle et de modélisation.

• La présentation de nos diagrammes.

2.2 Notions de modèle et de modélisation

2.2.1 Qu’est-ce qu’un modèle ?

Marvin Minsky donne la définition suivante d’un modèle [1] : « Pour un observateur B, un
objet A* est un modèle d’un objet A s’il permet à B de répondre à une question qu’il se pose
sur A ».

8
 Un modèle est une représentation simplifiée de la réalité en vue de réaliser quelque chose

(objet concret, système d’équations . . . ) qui se substitue au réel trop complexe ou inaccessible

à l’expérience et qui permet de comprendre ce réel par un intermédiaire plus connu ou plus

accessible à la connaissance.

2.2.2 C’est quoi une modélisation ?

La modélisation est une opération par laquelle on établit le modèle d’un système complexe,
afin de l’étudier plus commodément et de mesurer les effets sur ce système des variations de tel
ou tel de ses éléments composants (Giraud-Pamart Nouv.1974).
À d’autre façon la modélisation consiste à mettre au point un ensemble d’équation ou des
règles pour décrive un phénomène de façon reproductible et simulable. La modélisation infor-
matique des données est en réalité un processus de description de la structure des associations,
des relations et des impératifs liés à des datas disponibles. Elle permet de fixer des normes, tout
en codant des modèles de gestion des données dans une organisation.

2.2.3 Les trois vues principales de modélisation d’un logiciel

F IGURE 2.1: Les trois vues essentielles d’un logiciel.

9
 On utilise souvent plusieurs modèles pour décrire tous les aspects d’un système complexe,
plusieurs « vues ». On distingue le plus souvent, comme le montre la figure (2.1), trois vues
principales pour un logiciel : la vue fonctionnelle qui décrit les services rendus, la vus structu-
relle (statique) qui décrit les composants et la vue comportementale (dynamique) qui décrit les
évolutions.

2.2.3.1 Vue fonctionnelle :

La vue fonctionnelle a pour but de présenter l’architecture fonctionnelle du système d’infor-

mation en termes de fonctionnalités, indépendamment des modalités d’implémentation décrites
dans la vue applicative. La vue fonctionnelle s’adresse à la fois aux professionnels des métiers
et aux professionnels de l’informatique (cas du diagramme de cas d’utilisation).

2.2.3.2 Vue statique :

La vue statique représente des schémas de conception à caractère stable ou immobile pour
les différents processus de l’application (cas du diagramme de classes).

2.2.3.3 Vue dynamique :

La vue dynamique représente une vision microscopique du fonctionnement de l’application.

Elle sert à mettre en évidence les relations temporelles inter-objets en explicitant l’enchaînement
des échanges entre ces objets tout au long de la réalisation d’une fonctionnalité du système et
la représentation sous forme d’un automate du comportement de certains objets. Elle intervient
après la définition du modèle statique (cas du diagramme de séquence).

2.3 Qu’est-ce que le langage UML ?

UML (Unified Modeling Language) se définit comme un langage de modélisation graphique
et textuel destiné à comprendre et à définir des besoins, spécifier et documenter des systèmes, es-
quisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.
UML modélise l’ensemble des données et des traitements en élaborant différents diagrammes.
Il est à noter que UML n’est pas une méthode mais un langage qui a été adopté par toutes les
méthodes orientées-objet et est devenu le standard de l’industrie.

10
2.4 Vue fonctionnelle : diagramme de cas d’utilisation

2.4.1 Qu’est-ce qu’un diagramme de cas d’utilisation ?

En langage UML, les diagrammes de cas d’utilisation modélisent le comportement d’un

système et permettent de capturer les exigences du système. Les diagrammes de cas d’utili-
sation décrivent les fonctions générales et la portée d’un système. Ces diagrammes identifient
également les interactions entre le système et ses acteurs. Les cas d’utilisation et les acteurs
dans les diagrammes de cas d’utilisation décrivent ce que le système fait et comment les acteurs
l’utilisent, mais ne montrent pas comment le système fonctionne en interne. Les diagrammes
de cas d’utilisation illustrent et définissent le contexte et les exigences d’un système entier, ou
des parties essentielles d’un système. On peut modéliser un système complexe avec un seul
diagramme de cas d’utilisation, ou créer de nombreux diagrammes de cas d’utilisation pour
modéliser les composants du système. On développe des diagrammes de cas d’utilisation es-
sentiellement dans les premières phases d’un projet et on s’y réfère tout au long du processus
de développement.

2.4.2 Identification des acteurs

Dans le digramme de cas d’utilisation, les utilisateurs du système sont dépeints comme
des acteurs. Chaque acteur représente un rôle joué par une entité externe (utilisateur humain,
dispositif matériel ou autre système) qui interagit directement avec le système étudié. Dans le
cas de notre application le seul acteur qui interagit avec le système est le joueur.

2.4.3 Les cas d’utilisation

Un cas d’utilisation décrit une fonction qu’un système exécute pour atteindre l’objectif de
l’utilisateur. Un cas d’utilisation doit renvoyer un résultat observable qui est utile pour l’utilisa-
teur du système. Les cas d’utilisation contiennent des informations détaillées sur le système, les
utilisateurs du système, les relations entre le système et les utilisateurs et le comportement requis
du système. Les cas d’utilisation ne détaillent pas la manière dont le système est implémenté.
Chaque cas d’utilisation décrit un objectif particulier de l’utilisateur et explique comment l’uti-
lisateur interagit avec le système pour atteindre cet objectif. Le cas d’utilisation décrit toutes les
façons possibles dont un système peut atteindre, ou ne pas atteindre, l’objectif de l’utilisateur.

11
Dans le cas de notre application les cas d’utilisations qui interagissent avec le système sont :
Jouer, Choisir niveau, Choisir question, Répondre à la question, Consommer indice, Consom-
mer bonus 50/50, Obtenir plus d’aides (Un cas d’utilisation abstrait), Acheter vies, Acheter
bonus, Regarder vidéo publicitaire.

2.4.4 Notre diagramme de cas d’utilisation

la figure (2.2) illustre notre diagramme de cas d’utilisation .

F IGURE 2.2: Notre diagramme de cas d’utilisation.

2.4.5 La spécification détaillée des cas d’utilisation

Dans cette section, nous procédons à une analyse plus approfondie des besoins de notre ap-
plication en présentant une description textuelle détaillée de quelques cas d’utilisation. Particu-
lièrement, les cas d’utilisations suivants seront détaillés : Jouer, Consommer indice, Consommer
bonus 50/50, Regarder vidéo publicitaire.

12
2.4.5.1 Cas d’utilisation : Jouer

TABLE 2.1: Description textuelle du cas d’utilisation : Jouer.

Sommaire d’identification
Titre Jouer
Acteurs Joueur
Résumé Jouer avec le quiz
Description des scénarios
Préconditions Se trouver à l’interface d’accueil

1. le joueur appuie sur le bouton « jouer »,

2. Le jeu affiche la liste des niveaux,
3. le joueur choisit un niveau,
Scénario nominal 4. Le jeu affiche la liste des questions,
5. le joueur choisit une question,
6. Le jeu affiche les détails de la question,
7. le joueur répond à la question.

3a. Le joueur clique sur un niveau verrouillé :

Le jeu lui demande de recueillir le score nécessaire
au déverrouillage de ce niveau.
5a. Le nombre de vies égal à 0 :
Le jeu demande au joueur d’obtenir plus de vies.
7a. Le nombre de vies égal à 0 lorsque le joueur clique
sur une réponse :
Alternatives
Le jeu demande au joueur d’obtenir plus de vies.
7b. Le joueur choisit de consommer un indice :
Le déclenchement du cas d’utilisation Consommer
indice.
7c. Le joueur choisit de consommer un bonus 50/50
dans le cas d’une question à choix multiples :
Le déclenchement du cas d’utilisation Consommer
bonus 50/50.

L’état de certaines questions peut changer à l’état

« Résolue », déverrouillage possible de certains niveaux, le
Postconditions
score total et le nombre de vies et de bonus peuvent
changer.

13
2.4.5.2 Cas d’utilisation : Consommer indice

TABLE 2.3: Description textuelle du cas d’utilisation : Consommer indice.

Sommaire d’identification
Titre Consommer indice
Acteurs Joueur
Résumé Le joueur veut avoir un indice sur la réponse
Description des scénarios

• Se trouver à l’interface propre aux détails de la

Préconditions question désirée,
• Le nombre de bonus est supérieur à 0.

1. Le joueur appuie sur le bouton « indice »,

Scénario nominal 2. Le jeu affiche un indice sur la réponse,
3. Le jeu décrémente le nombre de bonus.

Alternatives Aucunes
Postconditions Un indice sur la réponse est affiché.

2.4.5.3 Cas d’utilisation : Consommer bonus 50 :50

TABLE 2.4: Description textuelle du cas d’utilisation : Consommer bonus 50 :50.

Sommaire d’identification
Titre Consommer bonus 50 :50
Acteurs Joueur
Le joueur veut éliminer deux suggestions fausses parmi les
Résumé
quatre suggestions possibles.
Description des scénarios

• Se trouver à l’interface propre aux détails de la

question désirée,
Préconditions • La question doit être une question à choix multiples.
• Le nombre de bonus est supérieur à 0.

1. le joueur appuie sur le bouton « 50 :50 ».

Scénario nominal 2. le jeu enlève deux suggestions fausses.
3. Le jeu décrémente le nombre de bonus.

Alternatives aucunes
Postconditions Deux suggestions fausses sont éliminées.

14
2.4.5.4 Cas d’utilisation : Regarder vidéo publicitaire

TABLE 2.5: Description textuelle du cas d’utilisation : Regarder vidéo publicitaire.

Sommaire d’identification
Titre Regarder vidéo publicitaire
Acteur principal Joueur
Acteur secondaire Réseau publicitaire
Le joueur veut obtenir plus vies ou de bonus en regardant
Résumé
une vidéo publicitaire.
Description des scénarios

• Se trouver à l’interface plus de vies,

Préconditions
• Le joueur doit être connecté au réseau Internet.

1. le joueur appuie sur le bouton « Regarder vidéo

publicitaire ».
2. le jeu envoie une demande de pub vers le réseau
publicitaire,
Scénario nominal
3. Le réseau publicitaire lui envoie la publicité,
4. Le jeu affiche cette publicité,
5. Le jeu ajoute un certain nombre de vies ou de bonus
au joueur à la fin de la vidéo.

Alternatives Aucunes
Postconditions Un certain nombre de vies ou de bonus est ajouté.

2.5 Vue statique : diagramme de classes

2.5.1 Qu’est-ce qu’un diagramme de classes ?

Un diagramme de classes fournit une vue globale d’un système en présentant ses classes, in-
terfaces et collaborations, et les relations entre elles. Les diagrammes de classes sont statiques :
ils affichent ce qui interagit mais pas ce qui se passe pendant l’interaction. En notation UML et
comme la montre la figure (2.3), une classe est représentée sous la forme d’un rectangle divisé
en plusieurs parties : le nom de la classe, les attributs (champs) et les opérations (méthodes).

15
 F IGURE 2.3: Diagramme de classes.

2.5.2 Notre diagramme de classe

La figure (2.4) illustre notre diagramme de classe.

F IGURE 2.4: Notre diagramme de classes

16
2.6 Vue dynamique : diagramme de séquence

2.6.1 Qu’est-ce qu’un diagramme de séquence ?

F IGURE 2.5: Diagramme de séquence.

Un diagramme de séquence est un diagramme UML (Unified Modeling Language) qui re-
présente la séquence de messages entre les objets au cours d’une interaction. Un diagramme de
séquence comprend, comme le montre la figure (2.5), un groupe d’objets, représentés par des
lignes de vie, et les messages que ces objets échangent lors de l’interaction. Les diagrammes de
séquence représentent la séquence de messages transmis entre des objets. Ils peuvent également
représenter les structures de contrôle entre des objets. Par exemple, les lignes de vie dans un dia-
gramme de séquence pour un scénario de banque peuvent représenter un client, un guichetier
ou un responsable d’agence. Les communications entre le client, le guichetier et le responsable
sont représentés par les messages entre ces derniers. Le diagramme de séquence représente les
objets et les messages entre ces objets.

17
 Dans notre cas, nous allons utiliser le diagramme de séquence pour décrire le comportement
de notre système vu de l’extérieur en tant que boite noir, c.à.d. sans montrer les détails propres
à sa réalisation, vis-à-vis des acteurs concernés.

2.6.2 Nos diagrammes de séquence système

Dans ce qui suit, quelques diagrammes de séquence système qui illustrent des scénarios re-
présentatifs de certains de nos cas d’utilisations sont présentés. Particulièrement, les cas d’utili-
sations suivants sont considérés : Jouer, Choisir niveau, Choisir question, Répondre à la ques-
tion, Consommer indice, Consommer un bonus 50/50, Regarder vidéo publicitaire.

2.6.2.1 Cas d’utilisation : Jouer

F IGURE 2.6: Diagramme de séquence système du cas : Jouer.

18
2.6.2.2 Cas d’utilisation : Choisir niveau

F IGURE 2.7: Diagramme de séquence système du cas : Choisir niveau.

2.6.2.3 Cas d’utilisation : Choisir question

F IGURE 2.8: Diagramme de séquence système du cas : Choisir question.

19
2.6.2.4 Cas d’utilisation : Répondre à la question

F IGURE 2.9: Diagramme de séquence système du cas : Réponde à la question.

20
2.6.2.5 Cas d’utilisation : Consommer indice

F IGURE 2.10: Diagramme de séquence système du cas : Consommer indice.

2.6.2.6 Cas d’utilisation : Consommer un bonus 50/50

F IGURE 2.11: Diagramme de séquence système du cas : Consommer bonus 50 :50.

21
2.6.2.7 Cas d’utilisation : Regarder vidéo publicitaire

F IGURE 2.12: Diagramme de séquence système du cas : Regarder vidéo publicitaire.

2.7 Conclusion
Dans ce deuxième chapitre, nous avons présenté l’essentiel de notre phase de modélisation
UML. Nous avons présenté la modélisation et ses différents côtés. Nous avons donné une brève
présentation du langage UML. Ensuite, nous avons défini les différents diagrammes UML dont
nous avons besoin et qui sont : le diagramme de cas d’utilisation, le diagramme de classes et le
diagramme de séquence.
Nous avons justement illustré comment ces trois diagrammes ont été utilisés afin de modé-
liser notre système cible selon les vues fonctionnelle, statique et dynamique, respectivement.
Dans le chapitre suivant, Nous nous intéresserons à la partie qui concerne réalisation de notre
application.

22
Chapitre 3
Réalisation

3.1 Introduction
Dans ce chapitre, nous nous s’intéressons à la réalisation et le développement de notre ap-
plication « Jeu Quiz ». Nous allons présenter dans un premier temps l’OS Android, nous spé-
cifierons les principaux outils de développement ainsi que les langages et techniques que nous
avons utilisés,. Nous finirons par présenter les scénarios les plus généraux de notre application
illustrés par des captures d’écrans.

3.2 Présentation d’Android

Android a été développé par Google. Il a été annoncé en 2007 et il est devenu une plateforme
ouverte en 2008. Android est un OS gratuit et complètement ouvert. C’est-à-dire que le code
source et les API sont ouvertes. Ainsi, les développeurs obtiennent la permission d’intégrer,
d’agrandir et de replacer les composants existants. La raison pour cela est qu’Android peut être
trouvée sur une gamme d’appareils de différents fabricants notamment, Samsung, Motorola et
HTC, et bien d’autres grands fabricants utilisent Android dans leurs dispositifs. Actuellement
Android est l’un des systèmes d’exploitation principaux et il est considéré comme une grave
menace pour l’iPhone.

23
3.3 Outils de développement

3.3.1 Android Studio comme IDE

Android Studio est l’environnement de développement intégré (IDE) officiel pour le déve-
loppement d’applications Android. Pour prendre en charge le développement d’applications au
sein du système d’exploitation Android, Android Studio utilise un système de génération basé
sur Gradle, un émulateur, des modèles de code et une intégration Github. On trouve qu’une
application Android doit s’exécuter sur tous les types d’appareils. Chaque appareil peut avoir
une version différente sur Android fonctionnant dessus. Chaque version d’Android peut ne pas
prendre en charge toutes les fonctionnalités requises par votre application. Ainsi, lors de la créa-
tion d’une application, vous devez garder à l’esprit la version minimale et maximale d’Android.
La version que nous avons utilisé durant le développement est : 11.0.10.

3.3.2 Le Kit de développement (SDK) d’Android

Le SDK d’Android

Le SDK Android (kit de développement logiciel) est un ensemble d’outils de développement

utilisés pour développer des applications pour la plate-forme Android qui est devenue le plus
grand rival d’Apple dans le domaine des smartphones.

La version du SDK cible

Le Framework utilisera Target Sdk Version pour déterminer quand activer certains compor-
tements de compatibilité Le niveau d’API auquel notre application a été conçue pour fonction-
ner : Target Sdk : 32 .

La version minimale du SDK

Min Sdk Version est la version minimale d’Android prise en charge par votre application.
Les utilisateurs exécutant une version d’Android antérieure à cette version ne pourront pas
installer votre application ou la voir dans le Play Store. Le niveau d’API minimal à partir duquel
notre application peut fonctionner correctement : min Sdk 21 .[2]

24
3.3.3 Le langage Java

Il existe plusieurs langages de programmation pouvant être utilisés afin de développer des
applications mobiles. Parmi les langages de programmation, nous pouvons citer en particulier
les deux langages (Java et Kotlin). Pour ce qui est de notre cas, nous avons choisi le langage
Java, Il réduit les coûts, raccourcit les délais de développement, favorise l’innovation et amé-
liore les services d’application. Avec des millions de développeurs utilisant plus de 51 milliards
de solutions JVM (Java Virtual Machine) dans le monde, Java reste la plateforme de déve-
loppement de choix pour les entreprises et les développeurs. Pour le développement de notre
application, nous avons utilisé comme version du JDK, la version 11.0.10.[3]

3.3.4 SQLite : système de gestion de bases de données relationnelles

SQLite (Structured Query Language) est un Système de Gestion de Base de Données (SGBD)
qui permet d’entreposer des données de manière structurée (Base, tables, champs, enregistre-
ments, etc.). Le noyau de ce système permet d’accéder à l’information entreposée via un langage
spécifique qu’on appelle SQL (Structured Query Language).
Dans notre application, nous nous sommes basés sur ce SGBD pour le stockage des in-
formations propres aux différents niveaux et questions. Pour l’insertion initiale de toutes ces
informations, nous avons utilisé l’outil DB Browser for SQLite, qui est un outil open source
visuel de haute qualité pour créer, concevoir et modifier des fichiers de base de données com-
patibles avec SQLite. Cet outil utilise une interface familière de type feuille de calcul, et les
commandes SQL compliquées n’ont pas besoin d’être apprises.
Outres les informations relatives aux différents niveaux et questions du Quiz et pour la
sauvegarde et la restauration du score total, du nombre de vies et aussi de bonus, nous nous
sommes basés sur les fichiers de préférences proposés par le système Android. [4]

3.4 Présentation de l’application

Dans cette section, on va présenter les principales interfaces de notre application qui ré-
sument l’essentiel des fonctionnalités proposées par notre application.

25
3.4.1 Interface d’accueil

F IGURE 3.1: Interface d’accueil.

3.4.2 Liste des niveaux

(a) Liste initiale des niveaux (b) Verrouillage du deuxième

avec un seul niveau verrouillé. niveau.

F IGURE 3.2: Listes des niveaux.

26
3.4.3 Liste des questions

(a) Liste initiale des questions.

(b) Liste des questions avec quelques

questions résolues et d’autres non ré-
solues.

F IGURE 3.3: Liste des questions.

27
3.4.4 Interface propre aux détails d’une question à choix multiples

(a) L’énoncé de la ques-
tion avec ses suggestions
possibles.
(b) La sélection d’une ré-
ponse fausse.
(c) La sélection d’une ré-
ponse correcte. Un com-
mentaire sur cette réponse
est affiché au-dessous de
l’énoncé de la question.

F IGURE 3.4: Interface propre aux détails d’une question à choix multiples.

3.4.5 Interface propre aux détails d’une question Vrai/Faux

(a) L’énoncé de la ques-
tion avec ses suggestions
possibles.
(b) La sélection d’une ré-
ponse fausse.
(c) La sélection d’une ré-
ponse correcte. Un com-
mentaire sur cette réponse
est affiché au-dessous de
l’énoncé de la question.

F IGURE 3.5: Interface propre aux détails d’une question Vrai/Faux.

28
3.4.6 Épuisement des vies et des bonus

(a) Épuisement des vies. (b) Épuisement des bonus.

F IGURE 3.6: La consommation des bonus.

3.4.7 Consommation de bonus

(a) Consommer un indice sur (b) Consommer un bonus

la question. Cet indice est af- 50 :50.
fiché au-dessous de l’énoncé
de la question.

F IGURE 3.7: La consommation des bonus.

29
3.4.8 Interface d’obtention davantage de vies et de bonus

(a) Interface Plus de vies. (b) L’obtention de 5 vies sup- (c) L’obtention de 5 bonus
plémentaire. supplémentaire.

F IGURE 3.8: Interface d’obtention davantage de vies et de bonus.

3.5 Conclusion
Dans ce 3ème chapitre de réalisation, nous avons présenté les différents langages de pro-
grammation propres au développement et à l’implémentation de notre application mobile. Nous
avons également procédé à la définition d’outils de développement avant de présenter les inter-
faces qui résument les principales fonctionnalités que notre application propose.

30
Conclusion générale

A l’issue de notre cursus de Licence, spécialité ISIL (Ingénierie des Systèmes d’Informa-
tions et du Logiciel), nous sommes amenés à entreprendre un projet de fin d’études. Nous étions
chargées de concevoir et de mettre en œuvre une application mobile de "Jeu Quiz ", dédiée à
toute personne instruite qui souhaite utiliser son temps libre pour enrichir ses connaissances et
élargir sa culture générale de manière ludique et conviviale.
Pour accomplir notre mission, nous avons mis en œuvre les connaissances que nous avons
acquises tout au long de nos cursus universitaires avec l’aide précieuse de nos professeurs.
Après avoir effectué une réflexion sur les exigences de notre application, nous avons pu
exprimer clairement nos besoins fonctionnels et non fonctionnels et déterminer les utilisateurs
cibles de notre application qui sont toutes les personnes instruites. Ensuite, nous sommes pas-
sées à la conception minutieuse et détaillée de notre application en se basant sur le langage
UML. Nous avons ainsi modélisé notre système à l’aide de trois types de diagrammes UML, à
savoir les diagrammes de cas d’utilisation, de classes et de séquences.
Enfin, nous avons présenté l’essentiel de la partie implémentation de l’application en dé-
taillant les outils de développement utilisés ainsi que les interfaces offertes à l’utilisateur, et en
récapitulant les principales fonctions fournies par notre application. En effet, ce projet nous a
permis d’apprendre et d’utiliser de nombreuses technologies telles que : Android Studio, Java,
XML, SQLite, etc.
Au final, nous espérons que notre travail sera une source de motivation pour tous ceux qui
souhaitent poursuivre une carrière dans le développement mobile, en particulier le développe-
ment Android.

31
Bibliographie

[1] J. Lonchamp, Analyse des besoins pour le développement logiciel : Recueil et spécification,
démarches itératives et agiles. Dunod, 2015.

[2] Présentation des niveaux d’api android. [Online]. Available : https ://docs.microsoft.com/fr-
fr/xamarin/android/app-fundamentals/android-api-levels ?tabs=windows

[3] Oracle java. [Online]. Available : https ://www.oracle.com/dz/java/

[4] Db browser for sqlite. [Online]. Available : https ://info.blaisepascal.fr/cpge-db-browser-

for-sqlite

32