Analyse et modélisation des systèmes d'information : introduction
Systèmes d'information
Un systèmes d'information est un système composite. Sa structure comprend les éléments hétérogènes suivants :
- des ressources techniques (dont une forte composant logicielle)
- des ressouces humaines
- des modes d'organisation
Le système d'information est destiné à manipuler (acquérir, mémoriser, traiter, transmettre, retrouver) des informations pour satisfaire les besoins d'une organisation.
Notion de modèle
Le modèle, ou modèle conceptuel, est une représentation réduite, simplifiée, abstraite d'un problème (le plus souvent d'un des aspects du problème).
Dans l'ingénierie, un modèle (par exemple un plan d'un bâtiment) permet de comprendre plus facilement le travail, de communiquer avec le client, de réduire les risques, de diriger le chantier, et constitue une partie du contrat.
Afin de communiquer, nous pouvons utiliser tous les moyens qui sont à notre disposition, mais nous devons garder à l'esprit que tous les moyens de représenter (de décrire) le modèle ne possèdent pas les mêmes caractéristiques. Parmi les moyens de description du modèle, nous pouvons détailler les suivants :
- la langue naturelle (parler du problème, écrire des phrases qui décrivent le problème).
- la notation « ad-hoc » (un schéma selon les conventions établies seulement par le rédacteur du document).
- les notations semi-formelles (selon une convension syntaxique établie et définie).
- les notations formelles (selon une convension syntaxique et sémantique établie et définie).
Ces moyens de description du système d'information sont classés du plus informel au plus formel1. Seuls les deux derniers points relèvent de la modélisation conceptuelle.
Nous sommes en droit d'attendre certaines qualités d'un modèle :
Abstraction : le modèle doit être abstrait pour nous permettre de nous focaliser sur les aspects importants du problème en oubliant les autres. Il doit toujours être une simplification du problème.
La langue naturelle
La langue naturelle est le moyen le plus facile de décrire un système d'information, car il ne nécessite normalement aucun apprentissage, que ce soit pour celui qui décrit le problème, ou pour celui qui l'écoute ou le lit.
Ce moyen est cependant le moins formel, et nous allons nous pencher sur ses « 7 pêchés capitaux »...
Ambiguïté
Selon le cadre de référence des interlocuteurs, le langage naturel est extrêmement sensible aux ambiguïtés. Un même mot (ou suite de mots) peut être interprété de différentes manières. Cela peut même se produire sans que les protagonistes en soient conscients, ce qui est le cas le plus grave, chacun étant persuadé que l'autre pense de la même manière que lui, ce qui fait que le désacord ne peut être constaté.
Bruit
Nous parlons de bruit lorsque nous sommes en présence d'éléments qui n'apportent rien d'utile à la description du problème.
Silence
Le silence est le « pêché d'omission », lorsque des éléments du problème ne sont pas évoqués.
Surspécification
Nous parlons de surpécification quand la description du problème contient des éléments de la solution.
Contradiction
Des parties de texte peuvent entrer en conflit avec ce qui a été énoncé auparavant.
Référence en avant
Lorsque la description du problème contient des éléments qui n'ont pas encore été définis, nous parlons de référence en avant.
Repentir
Parfois, certains éléments du problème sont décrits top tardivement, ou sont simplement rapidement évoqués en fin de spécification. Dans ce cas, nous parlons de « repentir ».
Les notations « ad-hoc »
« Un bon croquis vaut mieux qu'un long discours »Napoléon BonaparteLa notation « ad-hoc » est un moyen rapide pour communiquer et décrire le problème. Il ne nécessite pas d'apprentissage particulier, mais comme il n'est pas formel, il reste des risques d'ambiguïté. La syntaxe n'est pas clairement définie et dépend uniquement du rédacteur du document.
Les notations semi-formelles
La syntaxe des notations semi-formelle est clairement définie. Il est donc possible d'automatiser partiellement le processus de raisonnement (et de génération de code dans le cas de problèmes informatique).
Les notations semi-formelles sont souvent graphiques, et permettent (normalement) une compréhension assez intuitive du problème décrit. Cela nécessite quand même un certain apprentissage, mais ces convensions de syntaxe diminuent le risque d'ambiguïtés.
Les notations formelles
En plus d'une syntaxe parfaitement définie, la notation formelle nous apporte une sémentique également formelle, mathématique, et insensible aux interprétations multiples. Il est donc possible d'automatiser largement le raisonnement.
Cependant ce type de notation, s'il permet une communication sans ambiguïté, n'est pas accessible au profane car il nécessite un apprentissage plus conséquent. De plus, le temps de rédaction de telles spécifications est plus important.
Nous pouvons avoir des notations formelles textuelles (en langage mathématique), ou graphique (par exemple les diagrammes d'états).
Apprendre du modèle
Comment pouvons nous apprendre le problème à partir de notre modèle ? Comment utiliser notre modèle ?
Par construction
Nous devons nous poser des questions qui restent valables pour la construction du système.
Par inspection
Nous pouvons exécuter mentalement le système, mais ce procédé reste assez peu fiable.
Par analyse formelle
L'analyse formelle est normalement le processus le plus fiable, mais la maîtrise de la sémantique formelle nécessite un coût (de temps, d'apprentissage, etc.), et peut se révéler extrêmement difficile pour des problèmes NP-complets. L'analyse formelle peut être utilisée lors de la vérification, mais rarement dans le cas de la validation (car lors de problèmes NP-complets, nous ne pouvons tester de manière exhaustive les possibilités.
Par expérimentation
Nous pouvons procéder à des expérimentations en utilisant certains outils.
Version en cache
21/11/2024 09:56:22 Cette version de la page est en cache (à la date du 21/11/2024 09:56:22) afin d'accélérer le traitement. Vous pouvez activer le mode utilisateur dans le menu en haut pour afficher la dernère version de la page.Document créé le 05/06/2010, dernière modification le 27/10/2018
Source du document imprimé : https://www.gaudry.be/analyse-amsi.html
L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.
- ↑ Formel : plus un moyen est formel, moins il est sujet à l'interprétation et à l'ambiguïté.
- ↑ Formel vs précis : Le fait d'utiliser une notation formelle ne nous assure pas de la précision de notre modèle. Nous pouvons avoir un modèle formel (une seule interprétation possible) imprécis (certains points du problème ne sont pas mentionnés).
Références
IHDCB335 - AMSI : Patrick HEYMANS, Analyse et modélisation des systèmes d'information
(2009)
Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.
