Objectif SL pris en charge. Cible de première évaluation 2027 ; PDF officiel renvoyant 403 ; l'ancien résumé acquis est l'évaluation finale 2026. Le guide restant, les exigences d'évaluation et pratiques conservent leurs retenues enregistrées.
Prérequis : lisez les quantités et unités indiquées, utilisez l'arithmétique et les conditions du modèle ci-dessous. Chaque leçon développe sa propre méthode avant un transfert autonome.
Ce sont des exemples pédagogiques originaux ou explicitement fictifs, pas des mesures réelles ni des enquêtes évaluées achevées par des apprenants.
Un système de réservation scolaire peut fonctionner correctement et néanmoins échouer si les utilisateurs perdent l'accès ou si des données sont divulguées. Le succès inclut le contexte du système.
Commencez par une prédiction. Énoncez les quantités ou caractéristiques que vous compareriez, puis décidez quels éléments de preuve pourraient distinguer deux explications.
Construire le modèle
Un système informatique combine matériel, logiciel, données et personnes. Un réseau permet la communication via des protocoles. Les exigences doivent distinguer les fonctions des contraintes telles que la disponibilité, la sécurité et l'accessibilité.
authentification : Vérification d'une identité affirmée ; autorisation : Détermination des actions autorisées.
Choisir des preuves capables de le tester
Séparez l'authentification de l'autorisation. L'authentification vérifie l'identité ; l'autorisation détermine les actions autorisées. Un modèle de menace relie un actif précieux, une attaque possible et un contrôle approprié.
Utilisez un jeu de données fictif d'école pour définir les utilisateurs et les permissions. Tracez les flux de données, comparez la validation et la vérification, et spécifiez des tests pour les entrées normales, aux limites et invalides. N'utilisez pas de vrais identifiants ou de dossiers d'étudiants dans les exercices.
Travailler à partir de quantités connues
Énoncez les valeurs connues et leurs unités. Choisissez la relation dont les hypothèses s'adaptent à ce cas, puis réarrangez-la avant de substituer les valeurs.
Connu : un fichier contient 12 mégaoctets, où cet exemple définit un mégaoctet comme un million d'octets. Bits = octets×8 = 12×1,000,000×8 = 96,000,000 bits. À 8,000,000 bits par seconde, le temps idéal = taille/vitesse = 12 s, hors surcharge.
Exemple :
Un fichier de 40 millions de bits est transféré à 5 millions de bits par seconde. Trouver le temps idéal. Utiliser la même séquence : quantités connues → modèle → relation → substitution → unité et interprétation.
Vérifier la conclusion et ses limites
La bande passante n'est pas le débit réel bout en bout. Le chiffrement ne garantit pas à lui seul une autorisation correcte ni n'élimine tous les risques de sécurité.
Revenez à l'observation initiale. Expliquez ce que le résultat soutient, quelles conditions il suppose, et une manière de tester une explication concurrente.
Avertissement :
Le chiffrement garantit que chaque utilisateur dispose des permissions d'accès appropriées. Cette affirmation est fausse : La bande passante n'est pas le débit réel bout en bout. Le chiffrement ne garantit pas à lui seul une autorisation correcte ni n'élimine tous les risques de sécurité.
Clé :
Systèmes informatiques, réseaux et exigences : Séparez l'authentification de l'autorisation. L'authentification vérifie l'identité ; l'autorisation détermine les actions autorisées. Un modèle de menace relie un actif précieux, une attaque possible et un contrôle approprié.
Un décimal MB signifie un million d'octets ; multiplier par huit avant de diviser par le nombre de bits par seconde. Zéro donnée a une durée de transmission idéale nulle. Un débit non positif est rejeté ; les surcoûts réels sont hors de ce modèle arithmétique.
Objectif SL pris en charge. Cible de première évaluation 2027 ; PDF officiel renvoyant 403 ; l'ancien résumé acquis est l'évaluation finale 2026. Le guide restant, les exigences d'évaluation et pratiques conservent leurs retenues enregistrées.
Prérequis : lisez les quantités et unités indiquées, utilisez l'arithmétique et les conditions du modèle ci-dessous. Chaque leçon développe sa propre méthode avant un transfert autonome.
Ce sont des exemples pédagogiques originaux ou explicitement fictifs, pas des mesures réelles ni des enquêtes évaluées achevées par des apprenants.
Un petit message peut arriver en retard sur un lien à haute bande passante. La capacité et le délai mesurent des propriétés différentes.
Commencez par une prédiction. Énoncez les quantités ou caractéristiques que vous compareriez, puis décidez quels éléments de preuve pourraient distinguer deux explications.
Construire le modèle
Les paquets transportent des données adresses à travers un réseau. Un modèle en couches sépare les responsabilités telles que la signification applicative, la livraison du transport et le routage réseau. La bande passante décrit la capacité ; le débit est le taux de données atteint ; la latence est le délai.
débit : Taux atteint de transfert de données utiles ; latence : Délai ressenti lors d'une communication.
Choisir des preuves capables de le tester
Le temps de transmission dépend de la taille des données et du débit. Le délai total peut également inclure la propagation, le traitement et l'attente. Le chiffrement protège le contenu selon ses hypothèses mais n'élimine ni la congestion ni toute exposition de métadonnées.
Tracer le chemin d'un message en utilisant un modèle local documenté. Enregistrer la taille du corps utile, les unités et le temps mesuré. Utiliser les réseaux approuvés par l'école et des messages synthétiques ; ne pas scanner ou intercepter le trafic d'un autre utilisateur.
Travailler à partir de quantités connues
Énoncez les valeurs connues et leurs unités. Choisissez la relation dont les hypothèses s'adaptent à ce cas, puis réarrangez-la avant de substituer les valeurs.
Connu : un fichier de 8 mégabits traverse un lien de 2 mégabit/s. Temps de transmission idéal = taille/vitesse = 8/2 = 4 s. La surcharge de protocole, les autres utilisateurs et la latence peuvent rendre l'achèvement observé plus lent.
Exemple :
Un fichier de 12 mégabits traverse un lien de 3 mégabit/s. Calculer le temps de transmission idéal. Utiliser la même séquence : quantités connues → modèle → relation → substitution → unité et interprétation.
Vérifier la conclusion et ses limites
Un mégaoctet équivaut à huit mégabits avant de prendre en compte la surcharge. Un lien avec une vitesse nominale supérieure ne garantit ni faible latence ni points d'accès sécurisés.
Revenez à l'observation initiale. Expliquez ce que le résultat soutient, quelles conditions il suppose, et une manière de tester une explication concurrente.
Avertissement :
Une connexion à haute bande passante garantit zéro latence. Cette affirmation est fausse : Un mégaoctet équivaut à huit mégabits avant de prendre en compte la surcharge. Un lien avec une vitesse nominale supérieure ne garantit ni faible latence ni points d'accès sécurisés.
Clé :
Réseaux : latence, débit et livraison en couches : Le temps de transmission dépend de la taille des données et du taux de transfert. Le délai total peut aussi inclure la propagation, le traitement et l'attente. Le chiffrement protège le contenu selon ses hypothèses, mais ne supprime ni la congestion ni toute exposition des métadonnées.
Mesurer depuis le début de la transmission jusqu'à l'arrivée du dernier bit. Le temps de transmission série et le délai de propagation s'additionnent sous ce modèle idéal. Augmenter la bande passante ne change que le premier terme ; les sauts store-and-forward et l'attente ajouteraient d'autres termes.
Objectif SL pris en charge. Cible de première évaluation 2027 ; PDF officiel renvoyant 403 ; l'ancien résumé acquis est l'évaluation finale 2026. Le guide restant, les exigences d'évaluation et pratiques conservent leurs retenues enregistrées.
Prérequis : lisez les quantités et unités indiquées, utilisez l'arithmétique et les conditions du modèle ci-dessous. Chaque leçon développe sa propre méthode avant un transfert autonome.
Ce sont des exemples pédagogiques originaux ou explicitement fictifs, pas des mesures réelles ni des enquêtes évaluées achevées par des apprenants.
3.2
Bases de données relationnelles : une clé et une relation
Qu'est-ce qui expliquerait cette observation ?
Dupliquer l'adresse d'un utilisateur dans chaque commande peut produire des enregistrements contradictoires lorsque l'adresse change.
Commencez par une prédiction. Énoncez les quantités ou caractéristiques que vous compareriez, puis décidez quels éléments de preuve pourraient distinguer deux explications.
Construire le modèle
Une table relationnelle contient des lignes et des attributs. Une clé primaire identifie une ligne ; une clé étrangère fait référence à une clé citée dans une autre table. La normalisation peut réduire la duplication évitable et les anomalies de mise à jour tout en préservant des relations significatives.
clé primaire : Ensemble d'attributs identifiant de manière unique une ligne de table ; clé étrangère : Ensemble d'attributs faisant référence à une clé dans une autre table.
Choisir des preuves capables de le tester
Une jointure combine des lignes selon une condition spécifiée. Le nombre de résultats dépend de la cardinalité de la relation et des filtres. Une contrainte de clé étrangère impose une règle de relation ; elle ne chiffre pas automatiquement les données personnelles.
Concevez un petit jeu de données synthétique utilisateur-commande sans informations personnelles réelles. Déclarez les clés, testez les insertions en double et avec références manquantes, puis vérifiez le résultat d'une requête par rapport à un tableau attendu calculé manuellement.
Travailler à partir de quantités connues
Énoncez les valeurs connues et leurs unités. Choisissez la relation dont les hypothèses s'adaptent à ce cas, puis réarrangez-la avant de substituer les valeurs.
Connues : quatre clients ont respectivement 2, 0, 3 et 1 commandes. Une jointure interne de client vers commande retourne 2+0+3+1 = 6 lignes. Une jointure gauche conserve également le client sans commande comme une ligne appariée nulle, donnant 7 ici.
Exemple :
Trois clients ont 1, 3 et 2 commandes. Combien de lignes retourne le joint interne client-commande ? Suivez la même séquence : quantités connues → modèle → relation → substitution → unité et interprétation.
Vérifier la conclusion et ses limites
Une clé primaire ne doit pas être un nom de personne. Une jointure n'est pas une simple concaténation de tables. Utilisez des requêtes paramétrées pour les entrées non fiables plutôt que de construire du SQL à partir de chaînes brutes.
Revenez à l'observation initiale. Expliquez ce que le résultat soutient, quelles conditions il suppose, et une manière de tester une explication concurrente.
Avertissement :
Une clé étrangère chiffre automatiquement chaque ligne. Cette affirmation est fausse : une clé primaire ne doit pas être un nom de personne. Un joint n'est pas une simple concaténation de tables. Utilisez des requêtes paramétrées pour les données non fiables plutôt que de construire du SQL à partir de chaînes brutes.
Clé :
Bases de données relationnelles : une clé et une relation : Un joint combine des lignes selon une condition spécifiée. Le nombre de résultats dépend de la cardinalité de la relation et des filtres. Une contrainte de clé étrangère impose une règle de relation ; elle ne chiffre pas automatiquement les données personnelles.
Trace exécutable et limite
import sqlite3
db = sqlite3.connect(":memory:")
db.executescript("""CREATE TABLE c(id INTEGER PRIMARY KEY);
CREATE TABLE o(id INTEGER PRIMARY KEY, cid INTEGER);
INSERT INTO c VALUES(1),(2),(3);
INSERT INTO o VALUES(10,1),(11,1),(12,3);""")
for kind in ["INNER", "LEFT"]:
sql = f"SELECT COUNT(*),COUNT(o.id) FROM c {kind} JOIN o ON c.id=o.cid"
print(kind, db.execute(sql).fetchone())
db.close()
Sortie attendue :
INNER (3, 3)
LEFT (4, 3)
Le joint gauche conserve le client 2 avec des champs de commande nuls. COUNT(*) inclut cette ligne, tandis que COUNT(o.id) l'exclut. Les clés primaires distinguent les enregistrements ; le comptage des clients n'est pas celui des commandes. Le mot-clé joint interpolé provient d'une liste interne fixe, pas d'une saisie utilisateur.
Objectif SL pris en charge. Cible de première évaluation 2027 ; PDF officiel renvoyant 403 ; l'ancien résumé acquis est l'évaluation finale 2026. Le guide restant, les exigences d'évaluation et pratiques conservent leurs retenues enregistrées.
Prérequis : lisez les quantités et unités indiquées, utilisez l'arithmétique et les conditions du modèle ci-dessous. Chaque leçon développe sa propre méthode avant un transfert autonome.
Ce sont des exemples pédagogiques originaux ou explicitement fictifs, pas des mesures réelles ni des enquêtes évaluées achevées par des apprenants.
Modèles de données et apprentissage automatique responsable
Qu'est-ce qui expliquerait cette observation ?
Un modèle peut obtenir un bon score en apprenant un raccourci dans les données d'entraînement. L'évaluation doit tester la tâche visée sur des exemples inconnus appropriés.
Commencez par une prédiction. Énoncez les quantités ou caractéristiques que vous compareriez, puis décidez quels éléments de preuve pourraient distinguer deux explications.
Construire le modèle
Une base de données relationnelle utilise des tables, des clés et des relations pour organiser les données. L'apprentissage automatique estime des modèles à partir de données. Les données d'entraînement et d'évaluation jouent des rôles différents.
clé primaire : Ensemble d'attributs identifiant de manière unique un enregistrement ; fuite de données : Utilisation d'informations non disponibles au moment de la prédiction prévu.
Choisir des preuves capables de le tester
Une clé primaire identifie de manière unique un enregistrement ; une clé étrangère relie des enregistrements. Dans une prédiction, une fuite peut exposer des informations indisponibles au moment réel de la décision. La précision seule peut masquer une distribution cible déséquilibrée.
Utilisez des enregistrements de réservation fictifs pour identifier les entités, attributs et relations. Pour un exercice d'apprentissage, utilisez un jeu de données public non sensible, séparez les données d'entraînement et de test, et décrivez qui pourrait être affecté par les erreurs. La portée actuelle de l'objectif CS 2027 attend le guide acquis.
Travailler à partir de quantités connues
Énoncez les valeurs connues et leurs unités. Choisissez la relation dont les hypothèses s'adaptent à ce cas, puis réarrangez-la avant de substituer les valeurs.
Connue : un classificateur effectue 90 prédictions correctes parmi 100 cas. Précision = correct/total×100 = 90%. Si 90 cas appartiennent à une seule classe, prédire toujours cette classe donne la même précision et peut tout de même échouer sur tous les cas de la classe minoritaire.
Exemple :
Un modèle effectue 72 prédictions correctes sur 80. Trouver le pourcentage de précision. Utiliser la même séquence : quantités connues → modèle → relation → substitution → unité et interprétation.
Vérifier la conclusion et ses limites
Une haute précision n'est pas une preuve d'équité ou de compréhension causale. Une clé primaire de base de données n'est pas simplement le champ qui semble important.
Revenez à l'observation initiale. Expliquez ce que le résultat soutient, quelles conditions il suppose, et une manière de tester une explication concurrente.
Avertissement :
Un classificateur avec une précision de 90% doit traiter toutes les classes également bien. Cette affirmation est fausse : Une haute précision n'est pas la preuve d'une équité ou d'une compréhension causale. Une clé primaire de base de données n'est pas simplement le champ qui semble important.
Clé :
Modèles de données et apprentissage automatique responsable : Une clé primaire identifie de manière unique un enregistrement ; une clé étrangère relie des enregistrements. Dans la prédiction, une fuite peut exposer des informations non disponibles lors de la prise de décision réelle. La précision seule peut masquer une distribution cible déséquilibrée.
La précision divise les prédictions correctes par l'ensemble des cas ; le rappel positif divise les vrais positifs par les positifs réels. Sans cas positifs, le rappel est indéfini plutôt que zéro. Le jeu de données est fictif, sans modèle entraîné ni données personnelles.
Objectif SL pris en charge. Cible de première évaluation 2027 ; PDF officiel renvoyant 403 ; l'ancien résumé acquis est l'évaluation finale 2026. Le guide restant, les exigences d'évaluation et pratiques conservent leurs retenues enregistrées.
Prérequis : lisez les quantités et unités indiquées, utilisez l'arithmétique et les conditions du modèle ci-dessous. Chaque leçon développe sa propre méthode avant un transfert autonome.
Ce sont des exemples pédagogiques originaux ou explicitement fictifs, pas des mesures réelles ni des enquêtes évaluées achevées par des apprenants.
5.2
Algorithmes, traces et preuves de correction
Qu'est-ce qui expliquerait cette observation ?
Un algorithme peut fonctionner pour un exemple et échouer à une limite. Les tests doivent être conçus à partir de la spécification, et non uniquement du chemin heureux.
Commencez par une prédiction. Énoncez les quantités ou caractéristiques que vous compareriez, puis décidez quels éléments de preuve pourraient distinguer deux explications.
Construire le modèle
Un algorithme est une procédure finie et non ambiguë pour une tâche. Une trace enregistre les changements d'état. Un invariant de boucle décrit une propriété préservée par chaque itération et aide à justifier la correction.
algorithme : Procédure finie résolvant une tâche énoncée ; test aux limites : Test effectué à la limite de l'intervalle d'entrées autorisé.
Choisir des preuves capables de le tester
Énoncer les conditions d'entrée et les sorties attendues. Utiliser des cas limites, des collections vides si elles sont autorisées, des doublons et des valeurs invalides. Distinguer un algorithme erroné d'une implémentation défectueuse ou d'une exigence incomplète.
Tracer une recherche sur une petite liste fictive triée. Énoncer la convention d'indexation. Pour la recherche dichotomique, mettre à jour les bornes pour que l'intervalle restant se réduise et rejeter une entrée non triée sauf si le tri fait partie de la tâche.
Travailler à partir de quantités connues
Énoncez les valeurs connues et leurs unités. Choisissez la relation dont les hypothèses s'adaptent à ce cas, puis réarrangez-la avant de substituer les valeurs.
Connu : une recherche linéaire dans une liste de huit éléments peut nécessiter huit comparaisons lorsque l'élément recherché est le dernier ou absent. Doubler la longueur de la liste double le nombre maximal de comparaisons selon ce modèle. La recherche dichotomique réduit l'intervalle d'environ la moitié à chaque étape mais nécessite une structure ordonnée appropriée.
Exemple :
Une recherche linéaire scanne tous les 14 éléments sans correspondance. Combien de comparaisons d'éléments se produisent ? Utiliser la même séquence : quantités connues → modèle → relation → substitution → unité et interprétation.
Vérifier la conclusion et ses limites
Un échantillon de test réussi ne prouve pas la correction pour toutes les entrées valides. N'importez pas la syntaxe de pseudocode spécifique à Cambridge dans un cours du DI sans source de programme.
Revenez à l'observation initiale. Expliquez ce que le résultat soutient, quelles conditions il suppose, et une manière de tester une explication concurrente.
Avertissement :
Un échantillon de test réussi prouve qu'un algorithme est correct pour toute entrée valide. Cette affirmation est fausse : Un échantillon de test réussi ne prouve pas la correction pour toutes les entrées valides. N'importez pas la syntaxe de pseudocode spécifique à Cambridge dans un cours du DI sans source de programme.
Clé :
Algorithmes, traces et preuves de correction : Énoncer les conditions d'entrée et les sorties attendues. Utiliser des cas limites, des collections vides si elles sont autorisées, des doublons et des valeurs invalides. Distinguer un algorithme erroné d'une implémentation défectueuse ou d'une exigence incomplète.
Trace exécutable et limite
def first_index(values, target):
for index, value in enumerate(values):
if value == target:
return index
return -1
print(first_index([4, 7, 4], 4))
print(first_index([4, 7, 4], 9))
print(first_index([], 4))
Sortie attendue :
0
-1
-1
La boucle teste l'index 0 en premier, s'arrête sur une correspondance et retourne −1 uniquement après avoir épuisé la liste. Les doublons retournent donc le premier index. Une liste vide n'exécute aucun corps de boucle.
Objectif SL pris en charge. Cible de première évaluation 2027 ; PDF officiel renvoyant 403 ; l'ancien résumé acquis est l'évaluation finale 2026. Le guide restant, les exigences d'évaluation et pratiques conservent leurs retenues enregistrées.
Prérequis : lisez les quantités et unités indiquées, utilisez l'arithmétique et les conditions du modèle ci-dessous. Chaque leçon développe sa propre méthode avant un transfert autonome.
Ce sont des exemples pédagogiques originaux ou explicitement fictifs, pas des mesures réelles ni des enquêtes évaluées achevées par des apprenants.
7.2
Objets : état, comportement et interface
Qu'est-ce qui expliquerait cette observation ?
Deux objets de modèle de compte bancaire peuvent répondre à la même opération de dépôt tout en ayant des soldes différents.
Commencez par une prédiction. Énoncez les quantités ou caractéristiques que vous compareriez, puis décidez quels éléments de preuve pourraient distinguer deux explications.
Construire le modèle
Une classe définit un type avec un état et un comportement. Un objet est une instance. L'encapsulation contrôle l'accès via une interface afin que les opérations puissent préserver les invariants. L'héritage modélise une relation de type appropriée ; la composition modélise un objet contenant ou utilisant un autre objet.
encapsulation : Contrôle de l'accès à l'état via une interface ; instance : Objet individuel d'une classe.
Choisir des preuves capables de le tester
Un appel de méthode agit sur une instance particulière. Les changements d'état doivent respecter les préconditions et postconditions. Le polymorphisme permet au code d'utiliser une interface commune avec différentes implémentations lorsque le contrat est respecté.
Implémenter un petit modèle synthétique de compte ou d'inventaire. Tester deux instances indépendantes, rejeter les opérations invalides et les valeurs limites. Garder le modèle éloigné des comptes financiers réels et des identifiants.
Travailler à partir de quantités connues
Énoncez les valeurs connues et leurs unités. Choisissez la relation dont les hypothèses s'adaptent à ce cas, puis réarrangez-la avant de substituer les valeurs.
Connu : l'objet A commence à 40 unités et reçoit 15 ; l'objet B commence à 20 et reçoit 5. Les soldes finaux sont 55 et 25. Leur total est 80, mais aucun solde d'objet individuel n'est 80.
Exemple :
Une instance commence à 12 unités, ajoute 8 et retire 3. Trouver sa valeur finale. Utiliser la même séquence : quantités connues → modèle → relation → substitution → unité et interprétation.
Vérifier la conclusion et ses limites
Une classe n'est pas la même chose qu'une seule instance. L'héritage n'est pas automatiquement supérieur à la composition. Cacher simplement un champ ne prouve pas que toutes les opérations préservent un état valide.
Revenez à l'observation initiale. Expliquez ce que le résultat soutient, quelles conditions il suppose, et une manière de tester une explication concurrente.
Avertissement :
Deux instances d'une classe doivent toujours partager un seul solde. Cette affirmation est fausse : Une classe n'est pas la même chose qu'une seule instance. L'héritage n'est pas automatiquement supérieur à la composition. Cacher simplement un champ ne prouve pas que toutes les opérations préservent un état valide.
Clé :
Objets : état, comportement et interface : Un appel de méthode agit sur une instance particulière. Les changements d'état doivent respecter les préconditions et postconditions. Le polymorphisme permet au code d'utiliser une interface commune avec différentes implémentations lorsque le contrat est respecté.
Trace exécutable et limite
class Account:
def __init__(self, balance):
self.balance = balance
def withdraw(self, amount):
if amount < 0 or amount > self.balance:
return False
self.balance -= amount
return True
a, b = Account(15), Account(20)
print(a.withdraw(30), a.balance, b.balance)
print(a.withdraw(15), a.balance, b.balance)
Sortie attendue :
False 15 20
True 0 20
Le rejet intervient avant la mutation. Avec des soldes initiaux non négatifs, les retraits validés préservent un solde ≥ 0. Cette petite classe pédagogique expose des attributs ; une conception de production doit contrôler tous les chemins de mutation, sans supposer que la méthode seule garantit l'encapsulation.
Objectif SL pris en charge. Cible de première évaluation 2027 ; PDF officiel renvoyant 403 ; l'ancien résumé acquis est l'évaluation finale 2026. Le guide restant, les exigences d'évaluation et pratiques conservent leurs retenues enregistrées.
Prérequis : lisez les quantités et unités indiquées, utilisez l'arithmétique et les conditions du modèle ci-dessous. Chaque leçon développe sa propre méthode avant un transfert autonome.
Ce sont des exemples pédagogiques originaux ou explicitement fictifs, pas des mesures réelles ni des enquêtes évaluées achevées par des apprenants.
8.2
Analyse de cas en informatique : évaluer un système proposé
Qu'est-ce qui expliquerait cette observation ?
Un système de réservation scolaire proposé semble efficace, mais sa recommandation dépend des utilisateurs, des contraintes et des preuves. Un terme technique plausible seul ne constitue pas une décision justifiée.
Commencez par une prédiction. Énoncez les quantités ou caractéristiques que vous compareriez, puis décidez quels éléments de preuve pourraient distinguer deux explications.
Construire le modèle
Une étude de cas place les choix computationnels dans un scénario énoncé. Identifier les parties prenantes, les exigences, les preuves disponibles et les contraintes avant de recommander une architecture ou un algorithme. Distinguer un fait du scénario d'une hypothèse et d'une prédiction. Les compromis peuvent concerner la performance, la fiabilité, l'accessibilité, la confidentialité, la maintenance et le coût.
débit : Travail accompli par unité de temps sous une charge de travail énoncée ; test d'acceptation : Test vérifiant si une exigence utilisateur spécifiée est satisfaite.
Choisir des preuves capables de le tester
Une recommandation doit relier une exigence à un mécanisme et à un test observable. Par exemple, un problème de concurrence nécessite une stratégie empêchant les mises à jour conflictuelles, ainsi que des tests démontrant l'invariant. Une affirmation concernant une réponse plus rapide exige des mesures de charge de travail comparables plutôt qu'un simple label de complexité. Évaluer les alternatives dans les mêmes conditions énoncées.
Utiliser un scénario approuvé par l'école et des données synthétiques. Construire une matrice de revendication, preuves du scénario supportant, explication technique, limitation et test d'acceptation. Marquer explicitement les faits manquants et montrer comment la recommandation changerait si une hypothèse échouait. Cela prépare le raisonnement basé sur des cas sans reproduire une étude de cas d'évaluation IB indisponible ni inventer son barème de correction d'examen.
Travailler à partir de quantités connues
Énoncez les valeurs connues et leurs unités. Choisissez la relation dont les hypothèses s'adaptent à ce cas, puis réarrangez-la avant de substituer les valeurs.
Données connues : un prototype fictif traite 120 demandes réussies durant une observation de 30 secondes. Le débit est 120/30=4 demandes/s. Un second prototype traite 150 en 30 secondes, soit 5/s. Le second présente 25% de débit enregistré supérieur, mais aucune conclusion concernant la latence, le taux de défaillance ou la performance sous une charge plus élevée ne peut être tirée sans ces mesures.
Exemple :
Un système fictif traite avec succès 210 requêtes en 30 s. Calculer le débit. Utiliser la même séquence : quantités connues → modèle → relation → substitution → unité et interprétation.
Vérifier la conclusion et ses limites
Le débit n'est pas le temps de réponse. Une forte recommandation énonce les conditions dans lesquelles elle est censée fonctionner et les preuves qui pourraient l'infirmer. Les exigences officielles actuelles en matière d'études de cas en informatique doivent être vérifiées par rapport à la version d'évaluation applicable.
Revenez à l'observation initiale. Expliquez ce que le résultat soutient, quelles conditions il suppose, et une manière de tester une explication concurrente.
Avertissement :
Un débit observé plus élevé prouve automatiquement un temps de réponse inférieur pour chaque requête. Cette affirmation est fausse : Le débit n'est pas le temps de réponse. Une forte recommandation énonce les conditions dans lesquelles elle est censée fonctionner et les preuves qui pourraient l'infirmer. Les exigences officielles actuelles en matière d'études de cas en informatique doivent être vérifiées par rapport à la version d'évaluation applicable.
Clé :
Analyse de cas en informatique : évaluer un système proposé : Une recommandation doit relier une exigence à un mécanisme et à un test observable. Par exemple, un problème de concurrence nécessite une stratégie empêchant les mises à jour conflictuelles, ainsi que des tests démontrant l'invariant. Une affirmation concernant une réponse plus rapide exige des mesures de charge de travail comparables plutôt qu'un simple label de complexité. Évaluer les alternatives dans les mêmes conditions énoncées.
Trace exécutable et limite
for successful, attempted, seconds in [(240, 300, 30), (270, 300, 30)]:
if seconds <= 0 or attempted <= 0:
raise ValueError("Positive exposure required")
throughput = successful / seconds
failure_fraction = (attempted - successful) / attempted
print(throughput, failure_fraction)
Sortie attendue :
8.0 0.2
9.0 0.1
Le débit de succès et la fraction d'échec utilisent des dénominateurs différents. Un temps nul ou un nombre d'essais nul ne peut supporter ces taux. Ces résumés fictifs ne fournissent aucune preuve de latence, de coût ou de charge représentative.
