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.
English translation
You have asked to visit this site in English. For now, only the interface is translated, but not all the content yet.If you want to help me in translations, your contribution is welcome. All you need to do is register on the site, and send me a message asking me to add you to the group of translators, which will give you the opportunity to translate the pages you want. A link at the bottom of each translated page indicates that you are the translator, and has a link to your profile.
Thank you in advance.
Document created the 05/06/2010, last modified the 27/10/2018
Source of the printed document:https://www.gaudry.be/en/analyse-amsi.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
- ↑ 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).
References
IHDCB335 - AMSI : Patrick HEYMANS, Analyse et modélisation des systèmes d'information
(2009)
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.
