Documentation optimale

Cette documentation, pour ma part optimale, est trouvée pour les buts recherchés. Elle consiste en une solution qui utilise des concepts actuels en technologie (2008).

Champ d'application de la solution.

Le niveau où une solution intervient est représenté au moyen de l'architecture ANSI/SPARQ:

Le niveau externe nous est imposé.

La traduction vers le niveau conceptuel est faite au coût le moins élevé.

Une des possibilités serait d'utiliser une ontologie universelle qui permettrait d'éviter cette traduction.

Le niveau conceptuel est le champ d'application de ce document.

C'est également le niveau manquant dans la plupart des cas.

Le modèle de données à ce niveau est appelé “modèle de données conceptuel”, parfois le modèle logique (pourtant en ORM par physique l'on comprend le niveau physique) ou le modèle relationnel.

Souvent, l'analyste fonctionnel utilise, à défaut de mieux, l'architecture physique comme modèle conceptuel.

En fait dans beaucoup de cas ce qui se passe c'est que le fonctionnel affaires devient esclave de ce qui existe physiquement en IT.

Par sa lassitude propre la porte du fonctionnel vers le physique restera fermée pour le niveau conceptuel. Dans ce cas le niveau physique négociera directement avec le niveau externe sur les prestations à livrer et le conceptuel perdra tout contrôle.

Le niveau physique concerne les fichiers physiques effectifs ou les données sont stockées. Le modèle de données physique et conceptuel ne peut pas coïncider par définition.

La raison est que, au niveau physique l'on tient compte de critères différents de ceux qui prévalent au niveau conceptuel. Le critère de performance technique est primordial au niveau physique.

Un modèle de données générique poussé forme une contradiction avec la performance.

Un stockage d'une instance dans le cadre de l'approche donnée en approche objet forme également une contradiction avec la performance.

Afin de maintenir sa performance au niveau physique des variables sont optimalisées qui n'ont aucun lien conceptuel, notamment:

o l'organisation de la base de données: relationnel, hiérarchique, réseau ou orienté objet

o la topologie de la base de données: central, distribuée, fédéral,...

o le profil d'accès: création, entretien ou réquisition des données (en data warehouses par exemple)

o profil de données: statistiques quelles données en quelle mesure ces données sont réquisitionnées

o les caractéristiques physiques de la base de données

o le système de gestion de la base de données (DBMS)

o la connexion physique avec la base de données

o les protocoles de cette connexion

o les droits attribués à chaque utilisateur de cette DBMS

Lien niveau conceptuel / niveau physique.

Les types conceptuels peuvent être regroupés en sets et traduits vers un niveau physique, suivi d'une dé normalisation contrôlée et l'ajout d'indexes.

Le groupe d'utilisateur ciblé ne pourra instancier les données par rapport aux classes que de façon limitée.

La raison est que l'amplitude de données est simplement trop importante et nécessite des systèmes mainframe performants.

But

Comme l'on a pu apprendre des pages précédentes il y a un besoin de modelage et de documentation des produits, procès et procédures. Surtout si des investissements informatiques sont liés à ces activités.

Ceci pour arriver à un instrument pratique de contrôle des procès, risques et frais.

Surtout lorsque des services immatériels sont concernés, il y a une lacune, avec certaines conséquences spectaculaires mais également néfastes au niveau de la société en général.

La crise de crédit est la dernière dans une série qui ne se comparent qu'en ampleur.

Critères

Nous sommes donc en quête d'une méthode de documentation (et de rapportage par extension).

Celle-ci doit satisfaire les critères suivants:

l Etre constitué par un modèle de données

l D'une approche générique: adaptable au contenu modifié/nouveau

l Permettre la documentation et description de produits, risques, procès, algorithmes et procédures

l Permettre l'accès direct de personnes et de systèmes IT aux données

l Permettre une représentation graphique du contenu

Lors de notre recherche nous sommes tombés sur quelques possibilités.

Justification

Pourquoi utiliser un modèle de données génériques afin de documenter ?

Au niveau conceptuel nous devons travailler de manière générique afin de :

l Etre précis dans ses spécifications

l Ne pas modifier de façon permanente et coûteuse le modèle.

l Faire face aux développements nouveaux dans le monde extérieur et intérieur

l Les moyens et leur utilisation peuvent être schématisés

l Le schéma devient un modèle de données lorsque les tables peuvent être créés à partir de ce modèle

l Comme un modèle différent existe au niveau physique ou les instances spécifiques sont stockés les instances dans le modèle conceptuel ces données forment des données de test.

l Ces données de test peuvent survenir de données en “data warehouses” ou d'autres sources de données de production.

Pourquoi utiliser une taxonomie ?

Un concept défini est affiné d'avantage par rapport à son super type.

Par exemple: - Un humain est un objet physique

- Un Européen est une personne qui réside d'habitude sur le continent Européen

- Un Néerlandais est un Européen qui a son domicile ou sa nationalité aux Pays-Bas

De ce fait:

ü Une définition très précise peut-être donnée parce que les niveaux de spécialisation sont en principe illimité

ü Les propriétés et fonctions des types supérieurs sont hérités par les descendants

ü La définition est disponible à chacun dans un domaine

ü Le niveau adéquat peut être utilisé lorsqu'on aspire aux données utilisées.

Pourquoi un thésaurus/dictionnaire est nécessaire ?

Une réponse peut être trouvée sous la page:

http://www.fadyart.com/thesaurusFR.htm

Pourquoi utiliser une ontologie ?

l Afin de partager et enrichir le domaine dans lequel une société est active.

l Forme la base de connaissance (knowledge base) de la société.

L'on peut trouver plus de motivation sur:

http://www.fadyart.com/documentatieFR.htm

Approche

Différentes pistes auxiliaires qui mènent à des explications et solutions théoriques magnifiques pouvaient être suivies.

Puisque mes sources se trouvent presque exclusivement sur internet et que les pistes auxiliaires étaient littéralement sous la main par les hyper liens il fallait la discipline pour ne suivre que les chemins focusés vers le but attendu.

L'approche est donc également ici, comme sur les pages précédentes de la base vers le top.

Alternativement l'on aurait pu partir d'une approche académique: à partir d'une étude des théories sur l'information découvrir de nouvelles ou anciennes théories qui n'ont pas été mis en pratique jusqu'à maintenant.

Cette approche est pourtant réservée à des académiciens.

De mon côté je devais faire attention à ne pas tomber pour une solution théorique d'un problème théorique

Ce but est de trouver une solution concrète pour des problèmes concrets.

Lorsqu'il serait trouvé il serait intéressant de le faire évaluer d'un point de vue théorique.

Mis à part:

û La même chose vaut pour l'approche de nouveaux développements informatiques: rester focalisé sur le problème réel.

û Les méthodiques pour arriver à de nouveaux développements sont parfois irrésistibles du point de vue théorique.

û A la prise de connaissance, je restait parfois perplexe parce qu'ils démontraient clairement ne pas pouvoir être mis en pratique et restaient limité à une forme académique intéressante.

û Evidemment ceci ne fait pas défaut aux mérites de plusieurs outils qui sont effectivement applicables de manière pratique.

û Une évaluation plus fréquente de théories par leurs côtés pratique est opportun.

û La terminologie utilisée dans différentes approches est souvent très éloignée dans les diverses approches avec des significations souvent totalement différentes.

La proposition retenue.

Sur la proposition retenue l'on élaborera plus tard, voilà pourquoi cette contribution reste relativement restreinte sur le sujet.

La proposition comprends une ontologie élaborée suivant les standards OWL.

Les ontologies sont les fondations du web sémantique.

Par le web sémantique l'on comprends que les systèmes informatiques bâtissent des logiques à partir de données disponibles d'une certaine façon sur le web.

A l'aide d' une ontologie, aussi bien personnes que machines sont capables de comprendre l'information.

D'une part l'on dispose d'un modèle de données: concepts et relations entre concepts sont décrits et ordonnées dans une taxonomie.

Les concepts sont représentés par des classes.

Lorqu'on génère des éléments appartenant à des classes, ces individus, avec le modèle surposé formeront une base de connaissance (knowledge base).

La particularité à OWL est que ces standards permettent, au moyen de robots de recherche, d'accéder à des données stockées sur l'internet.

Après avoir été co-fondateur de l'internet Tim Berners-Lee avait un rêve: acquérir des connaissances, les agrandir et faire interpréter par des systèmes IT, depuis de l'information mis à disponibilité via l'internet.
OWL (Web Ontology Language) est un standard du W3C-consortium qui a été approuvé en 2004.

Participer à une communauté qui contribue à ce but, pendant que cette participation satisfait aux propres besoins en termes de buts décrits. Plus encore, que cette participation offre par son interaction avec d'autres ontologies un potentiel illimité d'optimalisation. Cette participation doit former le rêve de chaque personne engagée dans la matière de la connaissance.

La réquisition depuis des fichiers se fait par des robots (momentanément réduits en nombre) sur base d'un language spécifique: SPARQL qui est compréhensible par des humains.

Pour le moment ces réquisitions nécessitent une connaissance du modèle sous-jacent. Les robots nécessitent davantage d'optimalisations.

Nous ne pouvons concevoir établir une ontologie à la main.

Il faut un logiciel de développement afin de gérer les propriétés complexes et riches (relations inclues). Ces logiciels sont disponibles de manière limitée.

Je peux vous proposer le logiciel gratuit de l'université de Stanford: Protégé, dont la distribution se fait par le site http://protege.stanford.edu/

Il y a une documentation fantastique qui néanmoins retarde de quelques versions.

A ce jour (octobre 2008) je suggère la version 3.4 avec l'extension OWL.

Le logiciel est développé par la division IT de la faculté de médecine.

La faculté informatique dispose également d'un logiciel: Chimaera.

Probablement les paquets commerciaux se présenteront incessamment.

En plus il y a des robots de raisonnement qui vous aident à gérer les propriétés des concepts. Il peuvent être appelés en direct depuis le logiciel.

J'ai l'intention de publier dans les semaines à venir l'embryon d'une ontologie.

Sources

Vision de Tim Berners Lee sur le web sémantique: http://www.sciam.com/article.cfm?id=the-semantic-we

Pages du consortium W3 sur OWL: http://www.w3.org/2001/sw/WebOnt/

Mail listes sur OWL: http://lists.w3.org/Archives/Public/public-swbp-wg/

Web service ontologie au moyen de OWL: http://www.daml.org/services/owl-s/

Autres possibilités envisagées

Possibilité 1: UML

Une de ces méthodes est relatée à la programmation orientée objet

Au niveau programmation il y a 13 shémas-types distincts qui supportent le concept d'objets dans la programmation.

Dans la partie “sources” de ce document il y a d'amples références vers de la documentation sur le sujet.

Un groupe,”Business modelling and integration” a accédé en juin 2005 à OMG (objet management group). A ce jour, août 2008, il n'y a pas de “white paper”, pas d'agenda, pas d'aperçu de travaux exécutés, pas de road map. Que quelques présentations, de 2001 à 2006 dont le contenu n'a pas d'intérêt dans le cadre du sujet traité ici.

Annuellement une convention est organisée qui traite sur des tendances globales mais restant sans impact par rapport à mes recherches.

Ceci ne diminue pas les prestations d'OMG sur d'autres terrains, ils sont notamment à la base de UML (Unified Modelling Language).

Les plus pratiques de ces diagrammes sur le plan de l'utilité du côté affaires sont:

è les diagrammes d'activité (s'ils sont bien utilisés: les bons vieux schémas d'information). Ils démontrent qui (via les colonnes verticales) fait quoi (via les rangées horizontales). Ces modèles indiquent les conditions (évènements en language orienté objets, trigger en language plus ancien), sous lesquelles une action doit prendre place (par le symbole “option” ou le “OU” logique).

è Les diagrammes “Use case” qui simulent les interactions entre l'utilisateur et le logiciel.

Ces diagrammes peuvent offrir un support partiel pour la documentation que nous avons en vue.

Au total la version 2.0 contient 13 diagrammes.

Ils sont utilisés en relation à la programmation, à utiliser dans différentes circonstances et stades qui ne sont pas inclus dans le but recherché et ne seront donc pas pris en considération plus loin dans ce document.

A part sur le plan de l'UML le groupe OMG a développé différents standards.

Intéressant à savoir sur le plan de la communication entre plate-formes est que l'UML peut être converti en XML.

En ce moment nous ne pouvons pas déterminer dans quelle direction le groupe se propagera.

Il reste possible qu'au sein du groupe OMG un développement se réalise vers une documentation qui sera intéressante.

Je pense que l'option choisie pourra souplement satisfaire aux besoins nécessités par des développements en parallèle.

En conclusion cette option ne peut être retenue.

Concepts utilisables

Aucun.

Action

Rester attentif au développements éventuels.

Sources

Questions générales: http://ootips.org/

Support pour le développement OO :

http://www.cetus-links.org/oo_ooa_ood_tools.htmlpt

http://www.embedded.com/

http://www.sybase.com/products/modelingmetadata/powerdesigner/

Unified modelling language (UML) :

Description de comportements qu'un système dois adopter par un modelage Use Case:

http://www.iit.edu/~rhurlbut/xpt-tr-97-03.html

Information générale : http://www.holub.com/goodies/uml/index.html

http://www.objectsbydesign.com/tools/modeling_tools.html

http://www.agiledata.org/essays/dataModeling101.html

Logiciels (Tools) : http://www.puml.org/

http://www.objectsbydesign.com/tools/umltools_byCompany.html

http://www.oose.de/umltools.htm

Information modèle Use Case : http://www.pols.co.uk/use-case-zone/use-case-papers

http://usecasehelp.com/wp/white_papers.htm

Essais de modelage d'entreprise:

http://bmi.omg.org/

http://www.bpmi.org/

Possibilité 2: ISO 10303 – STEP – EPISTLE – EXPRESS

Contrairement à la possibilité précédente il est question ici d'un choix motivé, d'une méthodique existante et appliquée.

ISO 10303

A été conçu pour le transfert de données Cax (CAD, CAE, CAM,...), donc très technique et orienté matériel (je n'ai pas rencontré de services).

Les principaux domaines pionniers sont, à mes yeux:

û un modèle de données générique

û le développement d'un language descriptif et de communication: EXPRESS

û à ce language une forme graphique est liée qui est utilisé en large communauté: EXPRESS-G

û depuis un nombre d'années 2 autres propositions de standardisation ont été introduits: EXPRESS-P pour la description de procès et EXPRESS-I pour l'instantiation.

Des industries importantes utilisent le standard afin d'échanger des données avec leurs sous-traitants, de maintenir les données sur la construction de sites, la maintenance de machines,....

Comme principaux secteurs l'on peut citer le secteur pétrolier (avec Matthew West comme pionnier), de l'auto, le secteur chimique, le secteur nucléaire,...

Pour les intéressés: il est impossible de comprendre tout le standard sans en faire une vocation pour la vie. Il consiste notamment en de milliers de pages. L'approche correcte est de se concentrer sur le secteur qui constitue votre domaine d'activité.

STEP

Abréviation pour Standard for the Exchange of Product model data .

C'est le nom commun utilisé pour le standard ISO 10303.

EPISTLE

Abréviation pour

European

Process

Industries

STEP

Technical

Liaison

Executive

Coordonne les contacts informels entre industries transformatrices afin de promouvoir l'utilisation de STEP. Ce projet est jugé d'importance stratégique par l'UE et sponsorisé en tant que tel.

Dans les structures de données, l'on rencontre encore des entités avec plusieurs attributs, ou de l'information composée.

Résultat

Les raisons pour lesquelles je n'ai pas maintenu cette option sont:

- le manque d'une ontologie : la norme est très orientée vers la définition de produits, donc vers l'aspect dictionnaire de la documentation que nous avons en tête

- la norme est assujettie à des droits d'auteur

- les nouveaux développements ont cessé

- axés sur la description de produits et c'est un champ où ils sont dépassés par les développent dans des domaines nouveaux: UML, XML, semantic web,...

- afin à s'affilier à une norme pareille, il faut être soutenu par un secteur d'activité. Les secteurs bancaires et assurances ne sont pas tout de suite attirés

Concepts utilisables

EXPRESS-G aurait été utilisable si les standards étaient ouverts.

Je vous conseille d'en prendre connaissance car ces schémas sont souvent utilisés en industrie.

Sources

1. Général

Matthew West: http://www.matthew-west.org.uk/

NIST standard link to STEP: http://www.mel.nist.gov/msidstaff/sauder/SCL.htm

Wikipedia:

http://en.wikipedia.org/wiki/ISO_10303

http://www.wikistep.org/index.php/Main_Page

2. EXPRESS

http://deslab.mit.edu/DesignLab/dicpm/step.html

http://dblp.l3s.de/d2r/page/publications/conf/er/MaLF03

Aperçu des utilitaires (Tools) : http://pdesinc.aticorp.org/vendor/STEPtoolkits_vendor.html

Plate-forme sur laquelle un utilitaire performant peut être installé, gratuit et sous JAVA: http://www.eclipse.org/

Fournisseur d'utilitaires (Tools) :

http://www.steptools.com/

http://www.eurostep.com/

http://www.metabula.com/index.html

http://www.edrawsoft.com/express-g.php

http://www.jsdai.net/eclipse/express-g/screenshots

EXPRESS-G description:

http://ftp.si2.org/si2_publications/htmlSpecs/DR/part3.fm4.html

http://iaiweb.lbl.gov/IFC/IFC_Release_2.0/FINAL_Model/EXPRESS-G/

Data warehousing, modelage générique de données: http://www.dama-nj.org/presentations/Kalido_Generic_Data_Modeling.pdf

Epistle: http://www.matthew-west.org.uk/documents/princ03.pdf. Ce volume représente pour moi la bases et la signification du modelage générique.

Possibilité 3: Object Role Modelling

ORM est décrit pour la première fois vers 1996.

Ce qui est particulier c'est que l'on part de faits atomisés et que des relations entre ces faits. Des relations sont créés entre ces faits et nommés ainsi que les rôles joués par des attributs.

Contrairement à des modèles entités/relations (ER) et UML (class diagrammes) les attributs manquent donc en ORM. Les entités représentent des “faits élémentaires” qui sont reliés par des relations.

ORM peut être converti vers des structures sur base d'attributs comme ER ou UML.

Cette approche est adoptée dans la version .NET de Microsoft Visual Studio sous la partie “Enterprise Architecture” avec l'utilitaire Visio.

Lorsqu'on l'utilise là le code SQL peut être généré afin de créer les entités avec les restrictions sur les attributs comme définit graphiquement.

Ces entités peuvent être utilisés pour acquérir des données de test qui peuvent satisfaire ou non les règles d'affaires établies.

Visio peut être acquit séparément mais alors il manque la génération de code.

Concepts utilisables

ü Distinction entre la réalité du monde des affaires, les fonctionnalités de développement informatique (souvent orientation objet) et le stockage de données.

ü L'importance des relations qui permettent de maintenir des données au niveau atomique.

ü Possibilités graphiques très étendues

ü Possibilité de tester les règles d'affaires

Résultat

Les possibilités graphiques ne peuvent être interprétées sans connaissance des conventions.

La solution proposée dans le document donne accès direct aux données via Internet et ne nécessitent pas d'interface séparé.

Source

Base pour le développement d’ISO 15926: http://www.orm.net/

Possibilité 4: Modèle Entité/relation.

Ce modèle est décrit en 1976 par Peter Chen, depuis lors utilisé à large échelle et développe d'avantage afin de décrire la couche conceptuelle.

Le modèle semble le plus approprié pour décrire des ontologies.

Dans la littérature, l'on réfère souvent vers diagrammes ER (entité/relation) ou ERD.

Une entité décrit une donnée, avec d'éventuels attributs.

Une relation décrit ce qu'une entité signifie ou fait pour une autre entité.

Les relations peuvent avoir des attributs et ceux-ci peuvent joindre la relation dans le stockage

Il y a pleine disposition de paquets supportant ERD, même avec “reverse engineering” (création de graphiques à partir entités). Voir les sources.

Concernant les diagrammes il y a différentes conventions d'annotations possibles, notamment IDEF1x (ICAM DEFinition Language) et dimensional modeling.

Une entité est une donnée indépendante qui peut être identifiée.
Cette donnée peut être un aspect physique de la réalité comme un billet de banque, un concept comme un ordre d'achat en bourse ou un évènement comme l'exécution de l'achat en bourse d'un titre.

Ici l'on distingue le type d'entité, la catégorie ou la classe d'un côté et l'entité comme instance d'un type autrement. Il y a nombre de possibilité d'instance d'un type d'entité.

Dans ce contexte l'on distingue le modèle de connaissance et le modèle de stockage.

La connaissance est trouvée dans les types entités, les données de production dans les entités

Comparez à OWL et trouvez les différences.

Lorsqu'on compare les entités à des substantifs, les relations peuvent être comparées aux verbes qui lient 2 substantifs.

Par exemple si l'on considère les substantifs “le client” et “le titre” alors la relation acheter permet de formuler “le client” achète “le titre”.

Une entité est représentée par un rectangle, une relation par une facette.

Une réquisition depuis ce modèle de données utilise le langage ERROL(Entity Relationship Role Oriented Language) et quelques dérivés de celle-ci.

ERROL permet de faire de réquisitions en langage naturel ou en utilisant des diagrammes pour indiquer l'output requis.

ERROL est particulièrement adapté pour des ontologies et le web sémantique.

Aussi bien les entités que les relations peuvent avoir des attributs.

Par exemple:

le client peut avoir comme attribut un numéro de compte liquidités et un numéro de compte-titres
le titre peut avoir comme attributs un codes ISIN, un émetteur, une monnaie de cotation
la relation acheter peut avoir comme attribut un pays de cotation, une place bourse et un marché.

Les entités disposent d'une clé unique normalement.

Sources

Wikipedia: "http://en.wikipedia.org/wiki/Entity-relationship_model"

1. Proprietary ER diagramming tools (depuis Wikipedia)

· ModelRight: innovative and complete physical modeling tool - free community edition for MySQL.

· SmartDraw: point and click drawing method combined with many templates creates professional diagrams.

· Sparx Enterprise Architect: full UML 2.1 which includes data modeling.

· SQLyog Enterprise edition (GUI client for MySQL) has a diagramming tool that will generate ER-diagrams at the same time as reading or generating physical database objects and can save in a XML-based format for later use.

· Toad Data Modeler: ER modeling tool with support for both logical and physical modeling. Includes reverse engineering, SQL generation and report generation features for several db systems.

· Visio: The Enterprise Architect version supports generating and reverse engineering databases

· Visual Paradigm: Cross platform UML tool which supports round-trip engineering an ERD with a database.

2. Free software ER diagramming tools

Tools that can interpret and generate ER models, SQL and do database analysis.

· BrModelo: Utilitaire Brasilien de graphiques ERMs.

· DBDesigner-Fork: a fork of DBDesigner to make it work with other databases such as PostgreSQL.

· Ferret (software): ERM tool distributed with Debian and Ubuntu.[3]

· Gliffy: Online charting website.

· ModelRight: innovative and complete physical modeling tool - free Community Edition for MySQL.

· Mogwai ERDesigner NG

· MySQL Workbench: tool for graphically creating schemas (or, only in commercial version, reverse engineering schemas) [Beta Software], works with many database engines.

· Open System Architect: ER Diagram modeller the last version dates from 2005.

· Power*Architect: ER Diagram modeller in Java, forward and reverse engineering for several databases, open-source (originally proprietary software).

· StarUML - supports UML and ER Diagrams.

3. Free software Diagram tools

Ces utilitaires ne permettent pas de construire des diagrammes ER, il dessinent les formes sans connaissance de ce qu'ils signifient et ne génèrent donc pas d'SQL.

Kivio: flowcharting logiciel qui supporte les diagrammes ER.
Dia: programme permettant le dessin de plusieurs types de diagrammes, notamment ERD. Eventuellement avec des plug-ins (ex. tedia2sql) qui permet de générer de l'SQL.

4. ERROL (Entity Relationship Role Oriented Language)

Wikipedia: "http://en.wikipedia.org/wiki/ERROL"

Possibilité 5: ISO 15926

Ce standard est basé sur la norme ISO 10303 dont il maintient notamment le graphisme.

Il introduit des ontologies qui sont uniformes pour les industries différentes au niveau supérieur et spécialisés par industrie au niveau inférieur.

Le développement d'ontologies et les taxonomies adjacentes sont un développement important ou les industries n'ont pas attendu à les appliquer dans leur communication interne et pour la distribution de connaissance.

L'instantiation doit s'effectuer à partir d'une classe définie.

A nouveau Matthew West a contribué par son rôle de pionnier.

Les structures de données contiennent encore des entités avec plusieurs attributs, on parle d'information assemblée.

Les relations sont également stockées. Lorsqu'on se rends compte que les richesses de l'Europe ne sont pas constituées de ses matières premières, ni de ses sources d'énergie, mais se base sur l'application optimale de ses ressources rares, l'on doit constater que les relations sont tout aussi importantes que les entités

ISO 15926 introduit également la 4ième dimension: le temps en tant que clé d'accès à l'information.

Ainsi un moment de début et de fin seront introduits lorsqu'on gère une relation.

Concepts utilisables

Base de données génériques

Introduction d'une ontologie

Introduction d'une taxonomie

Introduction d'un thesaurus

Sources

Sites web généraux: http://15926.org/home/tiki-index.php

Sponsors: http://www.fiatech.org/

ISO: http://www.tc184-sc4.org/

EU implementation guide: http://www.european-pedc.eu/Presentations/Glendinning%20Ian.pdf

Ontology for process plants: http://www.tc184-sc4.org/wg3ndocs/wg3n1328/lifecycle_integration_schema.html

Projets:

http://www.btinternet.com/~Chris.Angus/epistle/documents/ep00108/ep00108.pdf

Smartplant project: http://nl.intergraph.be/programs.asp

Intergraph project: http://www.intergraph.com/

Bentley project: http://www.bentley.com/en-US/Products/ProjectWise+Lifecycle+Server/

Utilitaires (Tools): http://www.posccaesar.org/RDS/

Possibilité 6: GELLISH

Cette ontologie est basée initialement sur ISO 15926 et contient des éléments d'ORM (Object Role Modeling).

Ce qui vaut pour ISO 15926 vaut également pour Gellish.

Le but de l'architecte est d'arriver, avec l'aide des utilisateurs et spécialistes, à une ontologie universelle. Pareil exploit serait révolutionnaire.

De premier abord je suis sceptique dans cette possibilité.

La source de la taxonomie est dans le domaine scientifique (GELLISH est l'abréviation de Generic Engineering Language) et, bien que soutenu de façon élaborée par des philosophes, même meta-physiques (Kant), dans le domaine des services immatériels la taxonomie GELLISH laisse un sentiment d'étonnement.

Un exemple: un logiciel est considéré comme matériel parce que “il transporte des données”.

J'aurais pensé que ce soit un concept avec éventuellement un aspect matériel si le logiciel est stocké.

Le GELLISH dispose également d'une dimension “contexte” qui permet tout de même de différencier d'après les applications.

La méthode développée néanmoins est stupéfiante par sa simplicité.

La méthode

Þ L'information est également lisible par un utilisateur et interprétable par un ordinateur.

Þ Les structures de données ne permettent plus l'utilisation de plusieurs attributs, uniquement d'information atomisés

Þ Les relations sont stockées comme en ISO 15926.

Þ Il y a également distinction entre le modèle de connaissance et ses instantiation.

Þ Le modèle de connaissance contient une structure de classes qui devrait être commun au niveau supérieur maximal.

Þ Il n'est pas nécessaire de créer une classe avant de créer une instance.

Þ Les relations sont fortement standardisées.

Þ Toute l' ontologie est stockée dans une seule table.

Concepts utilisables

Voir sous ISO 15926 +

Relations standard avec définition séparée de rôles

Une seule table pour toute l' ontologie

Divers contextes (domaines) possibles pour chaque définition.

Sources

Site général: https://sourceforge.net/projects/gellish

WIKI : http://gellish.wiki.sourceforge.net/

STEPlib browser & editor: http://www.steplib.com/

Fournisseur de logiciel permettant l'utilisation d'un dialecte GELLISH: http://www.pkmsolutions.com/

L'on parle de dialecte GELLISH lorsque l'ontologie supérieure n'est pas suivie.

Sources

Je ne suis pas gêné d'avouer avoir utilisé au maximum Wikipedia (version Anglaise).

Comme robot de recherches j'ai utilisé Copernic (version gratuite).

Base et méthode de travail pour le modelage générique de données.

Le travail sur le site de Matthew West: http://www.matthew-west.org.uk/Documents/princ03.pdf me semble le plus approprié pour débuter chaque recherche.

Dictionnaire

Instantiation

La signification mathématique d'une instance doit être comprise.

L'on peut parler d'une empreinte sur base d'un modèle. Le modèle étant la classe définie.

Lorsqu'on conçoit une classe représentant des comptes espèces, alors le compte 000-0001111-11 est une instance de cette classe.

Logiciels avec approche objets (OO ou Object Oriented)

L'orientation objet est relatée à l'établissement et classification de types de procédures qui sont communs à une portée maximale.

L'objet est paramétré suivant les circonstances avec des propriétés (verbes) et méthodes (paramètres statiques).

Microsoft utilise également une extension de l'approche objet: le modèle de components. Un component est formé de plusieurs objets qui forment un programme indépendant.

Exemple un “ActiveX control”.

Le component est une étape plus avancée dans l'intégration: il sera part du système opérationnel de votre ordinateur par enregistrement dans le “registre”.

Il faut savoir que la signification dans les components de verbes/paramètres est inversée.

Concernant OO vous pourrez trouver de plus amples renseignement sur www.omg.org.

Au niveau de la gestion de données en OO on applique les modèles entités/relations classiques.

OO à des fonctionnalités au niveau des abstractions dans les comportements, pas dans les données.

A partir de notre niveau conceptuel nous n'avons pas grand chose à faire avec les techniques de programmation et, puisque les niveaux sont scindés, nous ne devons pas nous en soucier.

Les adeptes de méthodes de programmation procéduraux sont dans la défense, vu la facilité d'usage des objects dans les nouveaux projets.

Peut-être nous ferions bien d'écouter de temps en temps ces adeptes des procédures si nous constatons que nos PC ralentissent en corrélation avec les programmes installés.

Nous n'arrivons pas à étendre à temps nos RAM pour faire face aux objets nouveaux à traiter par chaque nouvelle installation.

Ontologie

Dans un domaine, la connaissance sur ce domaine est présentée d'une façon formelle.

Cela se passe par la définition de concepts et relations entre concepts.

Le mode d'opération habituel est le suivant:

Þ Définition de classes: sortes d'objets, concepts ou relations

Þ Attributs d'une classe: propriétés, point de vues possibles, paramètres d'une classe.

Þ Relations: manières de relier des classes entre elles

Þ Rôles: le rôle de chaque classe dans une relation.

Þ Fonctions: termes dans une comparaison ou un calcul qu'une classe peut prendre.

Þ Restrictions: restrictions dans les valeurs possibles comme attribut.

Þ Évènement: l'occurrence qui initialise une modification de valeurs des attributs ou relations.

Þ Règles: règles auxquelles les classes dans un domaine doivent satisfaire.

Þ Instantiation: voir définition.

La notion d'ontologie nous parvient de la philosophie.

Une belle documentation peut être trouvé à cette adresse:

http://www.radicalacademy.com/prcminicourseontology1.htm

Topologie fédérée.

Un système informatique qui consiste en différant systèmes locaux autonomes et qui partagent au minimum une partie de leur information.

Lorsque les components de ces systèmes existent de bases de données l'on parle de base de données fédérées.

http://fadyart.com/