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.
Deutsche Übersetzung
Sie haben gebeten, diese Seite auf Deutsch zu besuchen. Momentan ist nur die Oberfläche übersetzt, aber noch nicht der gesamte Inhalt.Wenn Sie mir bei Übersetzungen helfen wollen, ist Ihr Beitrag willkommen. Alles, was Sie tun müssen, ist, sich auf der Website zu registrieren und mir eine Nachricht zu schicken, in der Sie gebeten werden, Sie der Gruppe der Übersetzer hinzuzufügen, die Ihnen die Möglichkeit gibt, die gewünschten Seiten zu übersetzen. Ein Link am Ende jeder übersetzten Seite zeigt an, dass Sie der Übersetzer sind und einen Link zu Ihrem Profil haben.
Vielen Dank im Voraus.
Dokument erstellt 05/06/2010, zuletzt geändert 27/10/2018
Quelle des gedruckten Dokuments:https://www.gaudry.be/de/analyse-amsi.html
Die Infobro ist eine persönliche Seite, deren Inhalt in meiner alleinigen Verantwortung liegt. Der Text ist unter der CreativeCommons-Lizenz (BY-NC-SA) verfügbar. Weitere Informationen auf die Nutzungsbedingungen und dem Autor.
- ↑ 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).
Referenzen
IHDCB335 - AMSI : Patrick HEYMANS, Analyse et modélisation des systèmes d'information
(2009)
Diese Verweise und Links verweisen auf Dokumente, die während des Schreibens dieser Seite konsultiert wurden, oder die zusätzliche Informationen liefern können, aber die Autoren dieser Quellen können nicht für den Inhalt dieser Seite verantwortlich gemacht werden.
Der Autor Diese Website ist allein dafür verantwortlich, wie die verschiedenen Konzepte und Freiheiten, die mit den Nachschlagewerken gemacht werden, hier dargestellt werden. Denken Sie daran, dass Sie mehrere Quellinformationen austauschen müssen, um das Risiko von Fehlern zu reduzieren.
