CLASSE-RELATION

1- Modèle objet



I- Les 9 mots clés


Objet : élément physique réel, conceptuel ou abstrait (vecteur ensemble);

Abstraction : retenir les propriétés communes à un ensemble d'objets,

Encapsulation : masque ce qui est interne à l'objet. Ne présente que l'interface (*.hpp);

Classe,

Instance : créés par instanciation d'une classe;

Héritage : B, sous-classe, hérite de A, super classe ou classe mère,

Polymorphisme : traiter de façon uniforme un ensemble d'objets de nature différente;

Instanciation : passage de paramètres d'instanciation à la création d'objets,

Message : ordre (correspondant à une méthode) émis vers un objet.


Méthodes orientées objets : classe relation, OOA et OMT, OOD/HOOD/OOSD

Méthodes orientées comportement : Diagramme états-transitions, réseaux de Petri - SART

Méthodes orientées données : entité relation (Merise), IA-NIAM

Méthodes fonctionnelles hiérarchique : data flow, SADT, SASD - structure chart


Classe relation s'appuie sur entité relation étendu par l'héritage, les diagrammes états-transitions d'Harel, les pré et post conditions d'Hoare, le data flow, et la structuration en machines abstraites.


II- Les modèles


1) Le modèle Data Flow

Les notions : flots de données en E/S des processus, les processus, les zones de stockage. Les processus se redécomposent hiérarchiquement. Ce modèle est utilisé dans SADT, SASD, SART pour décrire le fonctionnement d'un système.



2) Le modèle Entité/Relation

Les notions : occurence ou représentant physique de l'entité qui l'a défini, entité (composée d'attributs), realtions conceptuelles entre les entités.


3) Le modèle dynamique, diagrammes états/transitions



4) Le modèle machines abstraites

Deux machines de même niveau ne peuvent pas communiquer. Une machine s'exécute sur les instructions des machines sous-jacentes.



5) Le modèle objet

L'objet réunit les modèles Entité/Relation (données), Machines abstraites (organisation/structuration), Automate/Data Flow (comportement). Pour décrire un concept avec ce modèle, ilo faut le nom (de la classe), l'héritage, les relations avec les autres classes, les attributs, les méthodes, et le prototype du concept (valeurs par défaut).


5) Le modèle Classe Relation

Un modèle doit être un véritable langage de modélisation : cohérence, complétude, capacité de vérification, précision, capacité de génération de code. Le modèle structurel décrit les notions du problème; le dynamique, le fonctionnement opérationnel ou comportement dynamique; l'opératoire donne le mode d'emploi. Le modèle peut être décrit aussi syntaxiquement.



CLASSE RELATION

2- Le modèle



I- Introduction


Les parties les plus stables d'un problème sont traités dans le modèle structurel, puis sont détaillées dans le modèle opératoire, et enfin les traitements dont la définition est par nature instable sont détaillées dans le modèle dynamique.


II- Modèle opératoire


Ici on a trois notions : pré/post conditions et l'automate de contrôle. Un automate de contrôle est un ensemble d'états et de transitions. On peut synthétiser les transitions vers des familles d'états en utilisant des états abstraits. Un état abstrait regroupe plusieurs sous-états; être dans un état abstrait = être dans l'un de ses sous-états. Un automate est donc un état abstrait.

Chaque transition est effectué par une méthode. Si une classe possède plusieurs automates, les méthodes de chacun d'eux sont indépendants.


III- Modèle dynamique


On donne :

- la description du comportement général d'objet (automate de déclenchement) pour les objets réactifs (objet ayant un comportement systématique dans certaines situations de leur environnement - ils sont minoritaires).

- la description du fonctionnement des méthodes (object flow) : s'applique toujours, mais son utilisation n'est pas nécessaire.

- des exemples de coopération d'objets (scénario) : ils permettent meilleure une compréhension. On numérote les transitions dans l'ordre du tirage.

- la vue globale des flux d'information dans un système (diagramme de flux) : aperçu global des échanges d'information.


1) Le modèle Object Flow

C'est l'adaptation du modèle Data Flow au modèle objet. Chaque modèle est attaché à une méthode d'une classe, qui est le processus d'entrée. Ce processus est décomposé en sous-processus, pour aboutir soit à une description textuelle, soit à du traitement, soit à des envois de messages, qui se réfèrent à d'autres méthodes, elles-mêmes pouvant avoir un Object Flow spécifique. Il ne s'agit donc pas du tout d'un arbre fonctionnel global, comme dans les cas des Data Flow.

En vue externe, une méthode est un processus qui transforme ses flux en entrée (paramètres in) en flux de sortie (paramètres out). La méthode peut être développée pour obtenir son Object Flow interne décrivant des enchaînements de traitements (sous-processus/message).

Les messages sont des boîtes blanches non décomposables : il faut accéder à la méthode invoquée. Les (sous-)processus sont des boîtes grises qui peuvent se décomposer et faire apparaître des boucles (la condition est en première ligne de la boîte).

Object Flow inclut également des structures de contrôle qui permet d'aiguiller les flux suivant des conditions.


2) Automate de déclenchement

Il permet de décrire les réactions systématiques d'un objet lorsque son environnement change. Une transition ne décrit plus une "possibilité" de déclenchement de méthode, comme l'automate de contrôle, mais bien une action systématique, sous certains états, certaines conditions, ou l'occurence de certains évenements. L'automate de déclenchement doit donc être déterministe et est lié à un automate de contrôle. L'automate de déclenchement présente, parmi toutes les transitions autorisées, celles qui sont systématiques.


III- Modèle structurelle


Deux notions apparaissent : les domaines et les schémas. Lorsque le nombre de lignes augmente, on gère le projet différemment :

-10 lignes : instructions séquentielles

-100 lignes : blocs d'instructions

-1000 lignes : sous-programmes

-10000 lignes : modules

-100000 : structuration

La structuration, c'est la modularisation à l'échelle supérieure, la séparation en lmots de travail, la séparation des problèmes, la présentation synthétique et descendante de la décomposition d'un développement, processus récursif jusqu'à l'identification des modules.


1) Domaine

Un domaine est un moyen de regrouper les concepts. On obtient ainsi les domaines gestion, comptabilité, mécanique, ... Dans les premier on trouve les concepts factures, commandes, ... Un domaine peut en utiliser un autre, et présente une interface utilisateur. Un domaine peut référencer un autre domaine, un schéma, ou une classe, mais ce n'est qu'un lien de référence : plusieurs domaines peuvent référencer le même élément.


2) Schéma

Un schéma est la représentation informatique d'un domaine. C'est un regroupement cohérent de classes, il partitionne l'application. On a trois types de classes : celles d'interface, pouvant être référencées par des schémas utilisateurs; celles de corps, accessibles qu'au sein du schéma; et les classes externes qui sont des classes vues, mais appartenant à d'autres schémas. Ainsi un schéma posséde une interface et un corps, un invariant. Un schéma permet donc de fournir un contexte de définition d'une classe.

Les schémas sont liés entre eux par des liens d'utilisation et d'héritage. Si S2 hérite de S1, alors les classes de S2 peuvent accéder à toutes les classes de S1 quelles soient d'interfaces ou de corps. L'interface de S2 est alors toutes les classes de l'interface de S1 plus ses propres classes d'interface.

Un schéma correspond à l'unité de développement d'une personne.


IV- Démarche de modélisation


Une classe doit définir réellement un concept connu ou accepté. On doit être capable de justifier du modèle, avec les propriétés factorisées. On doit définir l'identifiant de l'objet : en mode mono-processeur, c'est la référence.

Une relation peut être transformée en une classe et deux relations si le besoin est de gérer et manipuler les éléments associés à la relation initiale. Une relation entre un objet et une entité simple peut être transformée en attribut de l'objet.

Eviter les redondances des relations. Trouver la forme normales adéquates (comme entité/relation), le but étant d'éviter des erreurs de mises à jour. Dans la pratique, les modèles sont normalisés puis dénormalisés pour répondre aux exigences spécifiques des projets.


1) Formes normales

La première définit qu'un attribut de la classe considérée est obligatoirement élémentaire : pas d'imbrication d'objets. Transformation d'un attribut en relation.

La seconde dit que tout attribut (non inclu dans l'identifiant) dépend de tout l'identifiant.

La troisième dit que tout attribut ne dépend que de l'identifiant.

Une relation est en forme normale de Boyce-Codd ssi les seules dépendances fonctionnelles élémentaires sont celles dans lesquelles une clé détermine un attribut.

Une relation est en quatrième (généralisation de la FNBC) forme normale ssi les seules dépendances multivaluées élémentaires sont celles dans lesquelles une clé détermine un attribut.

Une relation R est en cinquième forme normale ssi toute dépendance de jointure est impliquée par les clés candidates de R.


2) Divers

Lorsque l'on ne peut pas émettre dans n'importe quel ordre des messages vers un objet, alors on a besoin d'un automate de contrôle. Il aide à clarifier et valider la cohérence des méthodes de la classe.

L'utilisation mutuelle, comme les graphes cycliques, entre schémas, sont interdites car ils empèchent une structuration des schémas. De plus, la transitivité de l'utilisation des schémas doit être explicite.

Pour les classes, il faut éviter les utilisations et les dépendances mutuelles. Pour cela on abstrait les propriétés inter-utilisées dans une classe mère dont on hérite ensuite.



Pour découvrir les classes on combine la recherche des données (informations, objets connus), la représentation des éléments gérés et manipulé, la recherche des modèles préalables, l'établissement du dictionnaire, la représentation globale du système, la justification par le besoin.

Un projet suit les phases dictionnaire, definition des utilisateurs avec leur besoin, definition des classes avec leur services, structuration des classes en schémas, contrôle des besoins par les scénarios d'interaction, mise à jour du dictionnaire.



V- Méthodologie classe-relation


Le processus de développement se décompose en plusieurs phases qui sont formalisées dans le cycle de vie du logiciel. Cela doit permettre de mesurer le travail effectué et celui restant à faire. Il existe plusieurs cycles de vie (en V, en cascade, en spirale, objet, ...), mais dans chacun les phases sont liées entre elles pour former une séquence d'activités. Le cycle de vie associé à classe-relation est le cycle en V.


La spécification apporte le document de spécification. Il comprend la représentation du système futur, la définition des besoins utilisateur, la définition des concepts d'interface, la spécification des domaines et services, la spécification détaillée, le dictionnaire, les scénarios d'interaction. On utilise pour cela les modèles structurel, opératoire et dynamique. On prépare aussi le dossier de validation.

On s'appuie sur l'analyse préliminaire (compréhension des besoins, cadre de développement, contraintes, grands domaines de service) et détaillée (ensemble des services fournis). Les documents d'analyse montre les domaines, le diagramme des flux, le modèle structuré par schémas et classes (avec invariants, pré/post conditions, automate de contrôle et de déclenchement), les scénarios.


La conception est décomposée en deux étapes. La conception préliminaire définit dans un document la description des contraintes de conception, les choix d'architecture (processus, serveur, sgbd, réseau, ...) et la représentation en schémas, la modélisation des concepts techniques. On pose également dans le dossier d'intégration le plan choisi.

La conception détaillée précise les services techniques et prépare la phase de développement. Le modèle de conception a pu être enrichit et modifié par rapport au modèle d'analyse par des classes techniques pour supporter les contraintes techniques. Ici, on founit le dossier de test unitaire (plan et spécification des jeux de test).

On s'aide des trois modèles, mais aussi du contexte de schéma.



VI- Hypergénéricité


Le but est l'automatisation du raffinement successif d'un modèle de spécification. En effet, la transformation du modèle de spécification en modèle de conception est souvent volumineuse et répétitive. L'hypergénéricité va permettre de définir séparément les règles de conception qui seront utilisées pour la transformation. L'hypergénéricité comprend le modèle classe-relation (méta-modèle), les directives (@IHM, @ClientServeur, ...) et les règles d'implémentation (règles H : pour toute classe ajouter une méthode Print dont le code est "pour tout attribut Print(attribut)" ).

A partir d'un modèle fonctionnel, on peut obtenir plusieurs modèle de conception suivant les choix techniques. Par exemple des donnees peuvent être accessibles par fichiers, par réseau, en client/serveur, par sgbd interposé... Les directives permettent d'annoter le modèle pour signaler un choix de transformation désiré. Les règles interprête ces directives pour une cible donnée. Ainsi, selon la directive appliquée et les règles appliquées, la classe correspondra à une fenêtre, une table SGBDR, une classe SGBDO, ...

Le développement débute donc par la réalisation du modèle de spécification, puis on définit les règles de transformation (langage H), on annote le modèle (directives), et on génère le code final. Avec le langage H, le méta-modèle regroupe les classes de H, et les modèles finaux sont vus comme des objets H.

Les instructions H sont disposées dans des méthodes, plaquéess sur le méta-modèle classe-relation. Les points de vues permettent alors de plquer des méthodes particulièressur le méta-modèle, selon le domaine d'intérêt. Ainsi les transformations SGBDO et SGBDR sont-elles disposées dans deux points de vue particuliers. Un point de vue peut en préciser un autre : les points de vue oracle et ingres précisent SGBDR; SGBDR et SGBDO précisent SGBD, ... Pour un projet, on choisit les points de vue qui nous interessent.

Pour nous contacter : siteclic.aro.microclic.com en remplaçant '.aro.' par @
3 requêtes