QCM : Modélisation des systèmes informatiques (24 questions)

Questions et réponses du QCM

1. À quoi sert la modélisation d’une partie d’un système informatique ?

À mesurer directement les performances du système en production
À reproduire fidèlement chaque détail du système sans le simplifier
À la rendre visible, partageable et discutable pour mieux la comprendre
À remplacer les échanges entre les personnes qui le conçoivent

À la rendre visible, partageable et discutable pour mieux la comprendre

Explication

La modélisation rend une partie du système visible et partageable afin d’en faciliter la compréhension. La mesure des performances en production relève d’une autre démarche.

2. Une équipe prépare un diagramme pour faciliter une décision de conception : quel critère indique le mieux que ce diagramme est utile ?

Il répond clairement à une question pertinente pour l’équipe
Il présente le plus grand nombre possible de détails techniques
Il ressemble aux diagrammes déjà employés dans d’autres projets
Il utilise une mise en page soignée et de nombreux symboles

Il répond clairement à une question pertinente pour l’équipe

Explication

La valeur d’un diagramme dépend de sa capacité à répondre à une question, et non de son aspect décoratif. Une présentation soignée ne suffit donc pas à établir son utilité.

3. Pourquoi un modèle informatique simplifie-t-il le système réel ?

Pour garantir que chaque élément réel figure dans la représentation
Pour mettre en évidence les éléments importants selon un objectif donné
Pour supprimer les aspects du système qui changent au cours du temps
Pour décrire les choix d’implémentation sans tenir compte du but visé

Pour mettre en évidence les éléments importants selon un objectif donné

Explication

Un modèle simplifie le système réel afin de rendre visibles les éléments pertinents pour un objectif donné. Une représentation exhaustive irait à l’encontre de cette fonction de simplification.

4. Un petit système comporte peu de classes et de serveurs, mais des dépendances implicites et des règles mal documentées ; que peut-on en conclure sur sa complexité ?

Elle dépend principalement du nombre d’utilisateurs actifs
Elle se déduit surtout du nombre de serveurs exploités
Elle reste faible puisque le nombre de classes est limité
Elle peut être élevée malgré la petite taille du système

Elle peut être élevée malgré la petite taille du système

Explication

La complexité ne se mesure pas seulement par la taille : des dépendances implicites ou des règles mal documentées peuvent rendre un système difficile à comprendre. Le nombre limité de classes ne suffit donc pas à conclure que sa complexité est faible.

5. Une équipe analyse les fonctionnalités, les règles métier, les rôles et les scénarios d’utilisation d’un produit ; quel aspect de la complexité étudie-t-elle ?

La complexité fonctionnelle liée à ce que le système doit faire
La complexité de déploiement liée à l’exploitation en environnement réel
La complexité des données liée aux relations entre les informations
La complexité technique liée aux composants et à leurs dépendances

La complexité fonctionnelle liée à ce que le système doit faire

Explication

La complexité fonctionnelle concerne ce que le système doit faire, notamment ses fonctionnalités, ses règles métier, ses rôles et ses scénarios. Les relations entre informations relèvent plutôt de la complexité des données.

6. Deux systèmes manipulent des volumes de données comparables, mais l’un comporte de nombreuses relations entre ces données ; quel facteur peut accroître sa complexité des données ?

Le nombre de fonctionnalités accessibles aux utilisateurs
La configuration des composants sur l’infrastructure
La diversité des rôles définis pour les utilisateurs
Les relations entre les données manipulées ou stockées

Les relations entre les données manipulées ou stockées

Explication

La complexité des données provient notamment des relations entre les données manipulées ou stockées, et pas seulement des données elles-mêmes. Le nombre de fonctionnalités concerne plutôt la complexité fonctionnelle.

7. Quand parle-t-on de complexité technique dans un système informatique ?

Lorsque son installation exige une configuration dans un environnement réel
Lorsque ses informations comportent de nombreuses relations entre elles
Lorsque son organisation interne devient difficile à comprendre, maintenir ou faire évoluer sans risque
Lorsque ses fonctionnalités et ses règles métier deviennent difficiles à expliquer aux utilisateurs

Lorsque son organisation interne devient difficile à comprendre, maintenir ou faire évoluer sans risque

Explication

La complexité technique apparaît lorsque l’organisation interne est difficile à comprendre, à maintenir ou à faire évoluer sans risque. Les règles métier difficiles à expliquer relèvent plutôt de la complexité fonctionnelle.

8. Une application possède peu de composants, mais une panne de sa base de données bloque plusieurs fonctionnalités ; quel facteur explique le mieux cette difficulté technique ?

Le volume des données stockées dans la base de données
La quantité de rôles utilisateurs définis pour l’application
Le nombre de composants pris isolément dans l’architecture
Les dépendances entre composants et leurs effets sur les fonctionnalités

Les dépendances entre composants et leurs effets sur les fonctionnalités

Explication

La complexité technique dépend des composants, mais surtout de leurs dépendances et des effets qu’une défaillance peut avoir sur le système. Le simple nombre de composants ne rend pas compte du blocage observé.

9. En quoi la complexité de déploiement se distingue-t-elle de la seule conception logicielle ?

Elle relie la conception aux exigences d’installation, de configuration, de sécurité et d’exploitation réelles
Elle représente surtout les relations entre les données manipulées par le système
Elle décrit principalement les fonctionnalités, les règles métier et les parcours des utilisateurs
Elle concerne l’organisation du code sans prendre en compte son environnement d’exécution

Elle relie la conception aux exigences d’installation, de configuration, de sécurité et d’exploitation réelles

Explication

Le déploiement relie la conception logicielle à la réalité opérationnelle, notamment à l’installation, à la configuration, à la sécurité et à l’exploitation. La seule organisation du code ne décrit pas ces exigences d’exécution.

10. Pourquoi le nombre d’acteurs impliqués peut-il accroître la complexité organisationnelle d’un système ?

Parce que chaque acteur peut avoir ses propres attentes vis-à-vis du système.
Parce que chaque acteur empêche les autres de définir les responsabilités.
Parce que chaque acteur ajoute automatiquement un composant technique au système.
Parce que chaque acteur utilise nécessairement un langage de modélisation différent.

Parce que chaque acteur peut avoir ses propres attentes vis-à-vis du système.

Explication

Les acteurs peuvent poursuivre des attentes différentes, ce qui rend leur coordination plus complexe. La diversité des langages de modélisation n’est pas la raison donnée pour cette complexité.

11. Un système fonctionne comme prévu lors des opérations normales, mais une faille permettrait un accès non autorisé. Quelle conclusion s’impose ?

Le bon fonctionnement normal ne suffit pas à établir que le système est sécurisé.
La faille relève du fonctionnement normal et ne nécessite pas d’analyse de sécurité distincte.
Le système est sécurisé dès lors que ses fonctions normales produisent les résultats attendus.
La sécurité dépend principalement du nombre d’acteurs impliqués dans le système.

Le bon fonctionnement normal ne suffit pas à établir que le système est sécurisé.

Explication

Un système peut fonctionner correctement tout en restant vulnérable ; l’analyse de sécurité doit donc dépasser le fonctionnement normal. Le bon déroulement des opérations ne prouve pas, à lui seul, l’absence de vulnérabilités.

12. Quelle description correspond à un modèle utilisé pour répondre à une question précise sur un système ?

Une représentation simplifiée du système construite en fonction de cette question.
Une copie complète du système destinée à reproduire toutes ses fonctions.
Un ensemble de détails techniques conservés sans objectif d’analyse défini.
Une réalisation opérationnelle qui remplace le système dans son environnement.

Une représentation simplifiée du système construite en fonction de cette question.

Explication

Un modèle est une représentation simplifiée du système conçue pour répondre à une question précise. Une copie complète n’est pas nécessairement simplifiée et ne correspond donc pas à cette définition.

13. Pour préparer un modèle destiné à répondre à un besoin particulier, quelle démarche respecte les principes de modélisation ?

Représenter le système sans le remplacer, écarter les détails inutiles et viser le besoin choisi.
Retirer des détails au hasard, sans tenir compte de la question à laquelle le modèle doit répondre.
Reproduire le système dans son intégralité, puis utiliser le modèle comme remplacement opérationnel.
Conserver tous les détails disponibles et éviter de préciser l’usage prévu du modèle.

Représenter le système sans le remplacer, écarter les détails inutiles et viser le besoin choisi.

Explication

Un modèle représente le système sans le remplacer, le simplifie en retirant les détails inutiles et répond à un besoin particulier. Une reproduction intégrale utilisée comme remplacement contredit les principes de représentation et de simplification.

14. Une équipe masque les détails d’implémentation pour mieux examiner les interactions entre les composants. Quel principe applique-t-elle ?

La documentation, qui remplace les détails par une réalisation exécutable.
Le point de vue, qui définit les éléments situés hors du système.
L’abstraction, qui fait ressortir les informations utiles à l’objectif.
Le périmètre, qui détermine les éléments inclus dans le modèle.

L’abstraction, qui fait ressortir les informations utiles à l’objectif.

Explication

L’abstraction consiste à masquer certains détails afin de mieux comprendre une partie du système et de mettre en évidence les informations utiles. Le périmètre délimite ce qui est inclus dans le modèle, mais ne désigne pas cette opération de simplification.

15. Lorsqu’une équipe décide quels éléments apparaîtront dans un modèle et lesquels seront laissés de côté, que précise-t-elle ?

Le niveau d’abstraction du modèle.
Le point de vue adopté sur le système.
Le besoin particulier auquel répond le modèle.
Le périmètre du modèle.

Le périmètre du modèle.

Explication

Le périmètre établit ce qui est inclus dans un modèle et ce qui reste à l’extérieur. L’abstraction consiste plutôt à masquer des détails pour faire ressortir les informations pertinentes.

16. Une équipe veut représenter graphiquement différents aspects d’un logiciel à l’aide de diagrammes adaptés à des questions précises. Quel outil correspond à cet objectif ?

C4, un modèle d’architecture organisé en niveaux de zoom.
UML, un langage graphique de modélisation.
Merise, une méthode d’analyse et de conception.
BPMN, une notation de processus métier.

UML, un langage graphique de modélisation.

Explication

UML est un langage graphique qui représente différents aspects d’un système logiciel avec des diagrammes répondant à des questions précises. Merise est une méthode d’analyse et de conception, et non le langage graphique décrit ici.

17. Pour structurer l’analyse et la conception d’un système d’information, notamment la modélisation des données, quelle approche distingue les niveaux conceptuel, logique et physique ?

UML, un langage graphique composé de diagrammes pour logiciels.
Merise, une méthode d’analyse et de conception des systèmes d’information.
BPMN, une notation décrivant des activités et des décisions métier.
C4, un modèle d’architecture logicielle organisé en quatre niveaux de zoom.

Merise, une méthode d’analyse et de conception des systèmes d’information.

Explication

Merise est une méthode d’analyse et de conception particulièrement utilisée pour modéliser les données, avec des niveaux conceptuel, logique et physique. C4 organise l’architecture logicielle selon des niveaux de zoom, et non selon ces trois niveaux.

18. Dans un modèle C4, une équipe veut examiner les éléments d’implémentation à un niveau plus détaillé que les composants internes d’un conteneur. Quel niveau doit-elle consulter ?

Code, qui décrit les éléments d’implémentation.
Components, qui décrit les composants internes d’un conteneur.
Context, qui situe le système, ses utilisateurs et les systèmes externes.
Containers, qui décrit les blocs exécutables ou déployables.

Code, qui décrit les éléments d’implémentation.

Explication

Le niveau Code du modèle C4 porte sur les éléments d’implémentation et offre un zoom plus détaillé que Components. Le niveau Components concerne les composants internes d’un conteneur, pas les détails d’implémentation eux-mêmes.

19. Avant de choisir un type de diagramme pour un projet, quelle démarche faut-il entreprendre en premier ?

Choisir la notation qui comporte le plus de symboles adaptés au projet
Identifier la question à étudier, par exemple les fonctionnalités, les échanges ou le déploiement
Sélectionner le diagramme le plus familier à l’équipe de développement
Déterminer le nombre de diagrammes nécessaires pour documenter le système

Identifier la question à étudier, par exemple les fonctionnalités, les échanges ou le déploiement

Explication

Le choix commence par la détermination de ce que l’on cherche à étudier, comme les fonctionnalités ou le déploiement. Choisir d’abord une notation revient à privilégier la forme du diagramme avant la question à laquelle il doit répondre.

20. Une équipe veut montrer quels acteurs utilisent une application et quelles fonctionnalités chacun peut solliciter. Quel diagramme convient à cet objectif ?

Un diagramme d’états-transitions, qui décrit les états traversés par un objet
Un diagramme de déploiement, qui localise les éléments installés sur les machines
Un diagramme de cas d’usage, qui associe les utilisateurs aux fonctionnalités du système
Un diagramme de séquence, qui ordonne les échanges d’un scénario dans le temps

Un diagramme de cas d’usage, qui associe les utilisateurs aux fonctionnalités du système

Explication

Le diagramme de cas d’usage indique qui utilise le système et quelles fonctionnalités sont concernées. Le diagramme de séquence décrit plutôt les interactions au fil du temps dans un scénario précis.

21. Pour analyser l’ordre des interactions entre plusieurs éléments pendant un scénario précis, quel diagramme faut-il privilégier ?

Un diagramme de déploiement, qui montre où les éléments du système sont installés
Un diagramme de séquence, qui représente les interactions entre éléments dans le temps
Un diagramme de cas d’usage, qui relie les utilisateurs aux fonctionnalités disponibles
Un diagramme d’activité, qui représente les étapes d’un processus

Un diagramme de séquence, qui représente les interactions entre éléments dans le temps

Explication

Le diagramme de séquence met en évidence les interactions entre éléments au cours du temps dans un scénario. Le diagramme d’activité porte sur les étapes d’un processus plutôt que sur l’ordre temporel des échanges entre éléments.

22. Une équipe doit préciser sur quelles machines les composants sont installés et comment le système s’exécute dans son environnement réel. Quel diagramme répond à ce besoin ?

Un diagramme de cas d’usage, qui indique les fonctionnalités utilisées par les acteurs
Un diagramme de séquence, qui représente les interactions au cours d’un scénario
Un diagramme de déploiement, qui représente l’emplacement des éléments installés
Un diagramme d’activité, qui décrit les étapes d’un processus métier

Un diagramme de déploiement, qui représente l’emplacement des éléments installés

Explication

Le diagramme de déploiement décrit où les éléments du système sont installés et aide à représenter son exécution réelle. Le diagramme de séquence porte sur les interactions dans le temps, sans établir l’emplacement d’installation des éléments.

23. Un diagramme emploie correctement les symboles attendus, mais ne permet pas aux lecteurs de comprendre le concept présenté. Comment faut-il juger sa qualité ?

Sa qualité dépend surtout du nombre de composants qu’il permet de représenter
Sa qualité est insuffisante, car un bon diagramme doit réellement faciliter la compréhension
Sa qualité est bonne, car l’emploi correct des symboles suffit à rendre le diagramme utile
Sa qualité est suffisante si le diagramme contient les détails techniques du système

Sa qualité est insuffisante, car un bon diagramme doit réellement faciliter la compréhension

Explication

Un diagramme de qualité aide réellement à comprendre un concept : la conformité des symboles ne suffit donc pas. L’emploi correct des symboles est pertinent, mais ne garantit pas à lui seul que le diagramme soit compréhensible.

24. Lors d’une évaluation critique, quelle vérification aide à déterminer si un schéma répond bien au besoin visé ?

Vérifier que chaque élément possède une description et que toutes les relations sont nommées
Vérifier son objectif, sa clarté, son adéquation à la question, ses omissions et ses niveaux mélangés
Vérifier son format, son emplacement dans le rapport et le nombre de pages associées
Vérifier sa conformité graphique, le nombre de symboles et la présence de détails techniques

Vérifier son objectif, sa clarté, son adéquation à la question, ses omissions et ses niveaux mélangés

Explication

L’évaluation critique porte notamment sur ce que le schéma cherche à montrer, sa clarté, son adéquation à la question, ses omissions et le mélange éventuel de niveaux. Vérifier les symboles et les détails techniques ne couvre pas à lui seul ces dimensions de pertinence.

Révisez avec les flashcards

Mémorisez les réponses avec 55 flashcards sur Modélisation des systèmes informatiques.

Que représente la modélisation d’un système informatique ?

Une partie du système sous une forme visible, partageable et discutable.

À quoi sert la représentation produite par la modélisation ?

À mieux comprendre le système informatique.

De quoi dépend la valeur d’un diagramme ?

De sa capacité à répondre à une question.

Voir les flashcards →

Approfondir avec la fiche

Consultez la fiche de révision complète sur Modélisation des systèmes informatiques.

Voir la fiche →

Cours similaires

Piliers de la programmation orientée objet

Programmation

AutoCAD et dessin architectural

Diagrammes statiques UML

Programmation orientée objet

Programmation

Bases de programmation en Python

Programmation

Identité numérique et données

Crée tes propres QCM

Importe ton cours et l'IA génère des QCM avec corrections en 30 secondes.

Générateur de QCM