Correspondances et différences de modèles et diagrammes

Précédente ] Accueil ] Remonter ]

Informatique de gestion et

système d'information

[ ISNet ]                        [ HES-SO ]


18 novembre 2003
Pierre-André Sunier
Laboratoire de Génie Logiciel
HEG-NE

Contenu

 

 

Introduction

Préalablement à la comparaison proprement dite, nous présentons les concepts de modélisation et de modèles de chacune des deux approches en nous appuyant sur des références bibliographique; pour chacune des deux approches, nous nous sommes attachés à collecter de l'information liée aux fondements des modèles que sont les métamodèles, les règles ou le langage de modélisation.
Concernant l'approche "objets", nous nous sommes naturellement basés sur le langage UML pour les aspects de modèle et sur Rational Rose pour les aspects liés à l'atelier de génie logiciel.
Concernant l'approche "fonctionnelle", comme nous ne pouvons nous appuyer sur l'universalité d'un langage de modélisation comme UML, nous nous sommes basés sur l'atelier de génie logiciel Oracle Designer; et plus particulièrement, sur la structure de son référentiel pour les aspects de modèle.

Nous effectuerons une comparaison des modèles en trois parties:

  • dans une première partie, nous mettrons en évidence quelques éléments significatfs de convergence ou de divergence entre les deux modèles;

  • dans une deuxième partie, nous nous inspirerons de l'ouvrage  De Merise à UML de N. Kettani, D. Mignet, P. Paré et C. Rosenthal-Sabroux publié en 1999 [KETT-98] pour établir un lien entre quelques principes essentiels de l'approche fonctionnelle (selon Merise) et notre expérience;

  • dans une troisième partie, nous tenterons de trouver les convergences ou divergences de modèle en utilisant les diagrammes d'UML comme  guides.  

Concepts de modèles et de modélisation

La modélisation est une activité indispensable à la compréhension de systèmes complexes: autant les méthodes de l'approche "fonctionnelle" que les méthodes de l'approche "objets" prônent la modélisation et la création de modèles.

Nous reproduisons ci-dessous quelques justifications significatives de chacune des deux approches;  ces considérations résultent de notre recherche documentaire.

Pour l'approche "fonctionnelle", selon P. Bouchy:

[BOU-95 p73] Pour appréhender et décrire un système sous une forme représentative, intelligible, communicante pour de multiples interlocuteurs qui ont parfois des objectifs différents, voire contradictoire, des cultures et des compétences variées, pas nécessairement convergentes, il n'est pas suffisant d'inventorier les événements à prendre en charge ou les besoins à satisfaire et de les faire valider par les utilisateurs finals; il est nécessaire de modéliser le système et si possible d'activer le modèle obtenu par une simulation, l'un et l'autre ayant l'agrément des utilisateurs potentiels.

Pour l'approche "objets", selon les pères d'UML

[BRJ-00 p 6] Les modèles permettent de mieux comprendre le système que l'on développe.

La modélisation permet d'atteindre quatre objectifs:

  • Les modèles nous aident à visualiser un système tel qu'il est ou tel que nous voudrions qu'il soit.

  • Les modèles permettent de préciser la structure ou le comportement d'un système.

  • Les modèles fournissent un canevas qui guide la construction d'un système.

  • Les modèles permettent de documenter les décisions prises.

Modèles en approche fonctionnelle avec Oracle Designer

Préambule

Nous avons lu la documentation disponible sur le site Oracle et l'aide en ligne qui accompagne Designer; les divers documents que nous avons trouvés chez le constructeur ne nous ont pas permis de dégager les concepts et règles fondamentales que nous cherchions.
Nous avons trouvé des bribes d'éléments intéressants dans les ouvrages suivants:

  • [DK-97] Oracle Designer/2000 Handbook, P. Dorsey et P. Koletzke, 1997

  • [DK-99] Oracle Designer Handbook, P. Dorsey et P. Koletzke, 1999

  • [ADI-99] Oracle Designer Generation, K. Atkins, P. Dirksen et Z.A. Ince, 1999

  • [EB-00] Software Engineering with Oracle, E. Bonazzi, 2000

  • [CM-00] Oracle8 Les outils de développement, C. McCullough-Dieter, 2000

Dans l'ouvrage Inside Oracle Designer/2000 de A. Lulushi publié en 1998 [AL-97], nous avons trouvé un argumentaire et une présentation du concept de référentiel qui nous permettra de servir de base à la comparaison des modèles des deux approches.
L'essentiel de  ce chapitre est basé sur les extraits de cet ouvrage.

Introduction

[AL-97 p112-116] Le référentiel (Repository) est à Designer ce que le cerveau est à l'homme. Il enregistre, contrôle et coordonne toutes les informations que vous collectez, traitez et utilisez durant l'analyse, la conception et le développement de systèmes d'information (informatisés). Il contient aussi l'intelligence pour traiter l'information et générer le code des applications pour de multiples environnements de développement comme OracleForms, Web PL/SQL, Visual Basic et d'autres. Ainsi, pour le système d'information informatisé ou projet en cours de modélisation, le référentiel sert simultanément de mémoire de connaissances et de système expert. La mémorisation des connaissances est réalisée par un ensemble de tables de base de données; la logique et l'intelligence du référentiel est est réalisée par des vues, des APIS PL/SQL et des triggers de base de données.

Les informations gérées par le référentiel peuvent être classées en: éléments, associations, informations topologiques relatives aux diagrammes et règles.

Éléments

Les éléments sont les unités de données dans lesquelles le référentiel sauve les informations relatives au projet. Le référentiel de Designer supporte près d'une centaine de types d'éléments différents et, en plus, il vous permet de créer vos propres types; par exemple, les unités d'organisation, les entités, les attributs d'une entité, les modules sont des types d'éléments. Les instances des types d'éléments sont les objets du référentiel grâce auxquels il mémorise l'information. L'unité d'organisation Service après-vente, l'entité PRODUIT, l'attribut CODE de cette entité ou encore le module Enregistrer annonce client sont des exemples de ces instances (de types) d'éléments.

Les éléments sont groupés en deux familles: les éléments d'accès primaire (PAC) et les éléments d'accès secondaires (SAC).

  • Primary Access Controlled (PAC) elements. Ces éléments appartiennent et sont contrôlés par le projet. Ils peuvent être manipulés directement... Les entités, les modules ou les tables sont des exemples de PAC elements d'un projet.

  • Secondary Access Controlled (PAC) elements. Ces éléments appartiennent et sont contrôlés par les PAC éléments... ils ne peuvent être manipulés que dans le contexte de leur PAC élément conteneur. Par exemple, un attribut ne peut être créé que pour une entité définie et accédée par l'intermédiaire de cette entité.

Dans la vue du référentiel ci-contre, nous voyons:

  • Le projet Phase2Version009, point de départ de l'arborescence des informations.
  • Les éléments type primaires (PAC) comme Business Fonctions, les fonctions, ou Entities, les entités.
  • Les occurrences d'entités comme CLIENT ou PRODUIT.
  • Les éléments type secondaires (SAC) comme Attributes ou Uniques Unique Identifiers de l'élément type primaire (PAC) PRODUIT.
  • Les occurrences d'attributs comme CODE de l'occurrence d'entité PRODUIT.

 

Associations

Les associations représentent les "dépendances" entre éléments d'un projets. tout comme pour les éléments, le référentiel est structurés en type d'associations et instances (de type) d'association. Dans la terminologie de Designer cette association entre éléments est nommée usages (utilisation). Il est possible de modéliser plusieurs utilisations (usages) d'éléments lors des activités d'analyse ou de conception. Par exemple, une entité est utilisée par une fonction ou est implémentée par une table...
Comme pour les éléments, vous utilisez les outils de Designer pour créer et maintenir les associations... Les associations peuvent aussi être créés automatiquement par les outils de Designer; par exemple Database Design Transformer qui crée une table à partir d'une entité et établit un lien entre les deux.
(Ce lien entre entité et table permet de mémoriser les règles appliquées lors de la transformation de modèle conceptuel en modèle logique de données)

Dans la vue du référentiel ci-contre, nous voyons:

  • Le paquetage des associations d'utilisation et le paquetage des associations d'inclusion.
  • Les types d'associations d'utilisation comme Used By Business Unit ou Implemented by Tables/Views.
  • L'occurrence d'association Implemented by Tables/Views entre l'entité PRODUIT et la table PRODUITS; cette association trace le lien entre l'entité PRODUIT et sa transformation au niveau logique en tant que table PRODUITS.
  • L'occurrence d'association Inclusions entre l'entité PRODUIT et le diagramme ET1_CREER_ANNONCE; cette association trace le lien d'inclusion de l'entité PRODUIT dans le diagramme l'entité ET1_CREER_ANNONCE.

 

Informations topologiques relatives aux diagrammes

Les diagrammes vous permettent de visualiser les éléments du projet et les associations entre éléments...
Pour vous fournir une vue des diagrammes consistante en permanence, Designer enregistre dans sa structure de données interne la topologie des diagrammes. Les informations de typologie incluent les coordonnées des objets, leurs positions relatives... il s'agit aussi d'attributs visuels des objets comme les couleurs de traits, de fond, d'écritures et ainsi de suite

Règles

Comme je l'ai mentionné précédemment, en plus de servir d'entrepôt des informations du projet, le référentiel de Designer fait office de système expert. Des centaines de règles implémentées dans le référentiel vous guident durant le processus d'analyse, de conception et de développement de systèmes d'information informatisés.

Ces règles ont trait:

  • au contrôle de syntaxe;

  • à la consistance et la complétude;

  • à la cohérence entre éléments et associations;

  • à l'automatisation de la transition de modèles entre niveaux d'abstraction différents;

  • à la génération de code.

Une importante catégorie de règles est celles qui dirigent ce qui peut être sauvé dans le référentiel, dans quel forme et sous quelles conditions... Collectivement, elles forment les règles des métadata (données de description des données), et leurs relations forment le métamodèle du référentiel.

Représentation

A partir de la présentation du référentiel faite par A. Luludhi et de la consultation bibliographique complémentaire, nous proposons le modèle suivant pour représenter le métamodèle de Designer:

Métamodèle UML

Préambule

G. Booch, J. Rumbaugh et I. Jacobson,  ont publié en 1998 , The Unified Modeling Language User Guide c/o Addison-Wesley; nous nous sommes référés à la traduction française de cet ouvrage, Le guide de l'utilisateur UML [BRJ-00].
L'essentiel de ce chapitre est basé sur les extraits qui nous semblent les plus significatifs de la présentation des concepts et du métamodèle d'UML.
Nous présenterons les éléments de méta-modèle sous forme de tableaux de synthèse et nous laissons le soin au lecteur de revenir à l'ouvrage de Booch, Rumbaugh et Jacobson pour plus de détails.

Introduction

[BRJ-00 p VII Préface] UML (Unified Modeling Language) est un langage graphique Conçu pour représenter, spécifier, construire et documenter les artefacts d'un système à dominante logicielle. Il permet d'écrire avec un langage standardisé les plans d'élaboration et de construction de logiciels. Il prend en compte aussi bien des éléments conceptuels que les les processus d'entreprises et les fonctions du système, que des éléments concrets tels que les classes écrites dans un langage de programmation, les schémas de bases de  données et les composants logiciels réutilisables.

[BRJ-00 p 14] Le vocabulaire et les règles d'un langage tel qu'UML régissent la manière de créer et de lire des modèles correctement mis en forme, mais ils n'imposent pas un choix des modèles à créer ni le moment de leur création. Ce rôle incombe au processus de développement logiciel (UP).

Modèle conceptuel d'UML

[BRJ-00 p 18] Pour comprendre UML, il est nécessaire de s'appuyer sur un modèle conceptuel (métamodèle) de ce langage, ce qui implique l'assimilation de trois éléments essentiels: les briques de base d'UML, les règles qui déterminent la manière de les assembler et quelques mécanismes généraux qui s'appliquent à UML dans son ensemble.

Dans les trois tableaux qui suivent, nous récapitulons les trois éléments essentiels du Langage UML.

Briques de base

Éléments Éléments structurels Classes
Interfaces
Collaborations
Cas d'utilisation
Classes actives
Composants
Nœuds
Éléments comportementaux Messages
États
Éléments de regroupement Paquetages
Éléments d'annotation Notes
Relations Dépendance  
Association
Généralisation
Réalisation
Diagrammes Structure Diagrammes de classes
Diagrammes d'objets
Diagrammes de déploiement
Diagrammes de composants
Comportement Diagrammes de séquence
Diagrammes de collaboration
Diagrammes de cas d'utilisation
Diagrammes d'états-transitions
Diagrammes d'activités

Nous avons créé ce tableau à partir d'une synthèse des pages 18 à 28 de [BRJ-00]

Règles sémantiques

Noms La manière de désigner les éléments, les relations et les diagrammes
Contexte L'environnement qui donne une signification bien précise à un nom
Visibilité La manière dont ces noms peuvent être vus et utilisés par d'autres
Intégrité La manière dont les objets établissent des relations correctes et cohérentes entre eux
Exécution Les conséquences de l'exécution ou de la simulation d'un modèle dynamique

Nous avons créé ce tableau à partir de la liste des règles d'UML présentées en page 28 de [BRJ-00]

Mécanismes généraux d'UML

Spécifications Énoncé textuel
Décorations Notation graphique unique
Distinctions communes Classes et objets
Interfaces et implémentations
Mécanismes d'extensibilité Stéréotypes
Étiquettes (tagged values)
Contraintes

Nous avons créé ce tableau à partir d'une synthèse des pages 29 à 33 de [BRJ-00]

Comparaison des métamodèles

Traits significatifs

Vu l'universalité d'UML, nous choisissons d'établir cette comparaison à partir du métamodèle d'UML et en donnant les éventuelles explications de convergences ou de divergences du métamodèle de l'AGL Oracle Designer.

Dans un premier temps, nous proposons une grille comparative des  traits significatifs des deux méta-modèle.

Approche objets
UML
Approche fonctionnelle
Oracle Designer
Remarques
Eléments

Eléments

Les éléments existent dans les deux métamodèles, toutefois leurs spécialisations diffèrent
Eléments d'annotation Designer permet d'annoter tout élément mais, un élément spécifique d'annotation n'existe pas
Relations Associations Les associations de Designer incluent implicitement aussi des notions de réalisation, de généralisation ou de dépendance
Diagrammes Les diagrammes sont des éléments comme les autres pour Designer.
Informations top. des diagrammes Naturellement, un AGL comme Rose de Rational conserve aussi ces informations de rendu des éléments ou relations apparaissant dans un diagramme
Règles sémantiques Règles Toute construction de modèle doit respecter des règles de fond et de forme
Mécanismes généraux d'UML Plusieurs des mécanismes généraux d'UML se trouvent dans Designer sous une forme ou une autre.

Les énoncés textuels et la décoration graphique sont également implantés par Designer.
Le référentiel de Designer est ouvert et extensible; via les APIs, l'utilisateur peut étendre le métamodèle du référentiel.

Dans un deuxième temps, nous proposons une grille comparative détaillée pour les éléments d'une part et pour les relations d'autre part.
Nous avons rédigé un chapitre spécifique pour la comparaion des diagrammes. Mais. à titre de résumé, nous avons inclus une grille comparative dans ce chapitre de comparaison des métamodèles.

Eléments

Approche objets
UML
Approche fonctionnelle
Oracle Designer
Remarques
Classes

Entités

Les classes et plus particulièrement les entités métier peuvent être "assimilées" aux entités de l'approche fonctionnelle.
Plus de détails

Les classes couvrent un champ plus large que les entités de l'approche relationnelle; toutefois, d'autres éléments de l'approche fonctionnelle peuvent être assimilées aux classes.
Par exemples 

  • les acteurs peuvent être assimilés aux classes stéréotypées "Acteurs";
  • les modules peuvent être assimilés aux classes stéréotypées "Frontière" ou "Contrôle"
Interfaces Vues
Portées de procédures
Les interfaces n'existent pas en tant que telles mais un parallélisme peut être établi avec certains concepts de l'approche fonctionnelle comme par exemple:
  • les vues du modèle logique de données sont un service offert par les tables qui réalisent le stockage et la gestion de l'intégrité des données.
    Plus de détails
  • les paquetages PL/SQL sont dotés d'un fichier d'interface, la spécification des services offerts, et d'un fichier de code, la réalisation des services.
    La modélisation de la portée (publique ou privée) des fonctions et procédures font office de spécification de l'interface du paquetage.
Collaborations Hiérarchie de processus ou de fonctions

Arborescences de modules

Une certaine analogie peut être tirée avec le concept de de découpage en étapes des processus et fonctions.
Exemple:
Cas d'utilisation Processus ou fonctions Les processus pour l'aspect métier et les fonctions pour l'aspect système tentent à définir les services ou fonctions attendue par les divers "utilisateurs".
Classes actives -
Composants Modules Les modules sont de véritables composants qui fournissent un service; ces modules servent de spécifications pour la génération de code; le code peut être généré pour de multiples plate-formes d'exécution.
Nœuds -
Messages Événements d'entrée
Événements de sortie

Flux

Les événements d'entrée (trigger) de la modélisation des processus sont des messages initiateurs de processus; les événements de sortie sont des messages terminateurs de processus.

Les flux sont des échanges entre processus et/ou fonctions; plus spécifiquement pour les DFD, les flux transportent des données. Ces flux concourent à déclencher les traitements supportés par les fonctions.

Etats -
Paquetages Paquetages Les paquetages sont utilisés par Designer aussi bien pour regrouper des éléments de modèles que pour la réalisation de logiciels sous forme fichiers de code.

 

Relations

Approche objets
UML
Approche fonctionnelle
Oracle Designer
Remarques
Dépendance Au niveau du référentiel, les relations entre éléments de même niveau d'abstraction représentent, souvent, des relations de dépendance.

Dans l'exemple ci-contre, nous voyons que le module GB15 utilise la table CLIENTS pour spécifier son comportement. De fait, le module GB15 dépend de la table CLIENTS.

Association Association L'association entre entités est un concept identique à l'association entre classes.
Généralisation La généralisation existe sous forme de classificateurs d'entité; la généralisation est réalisée sous forme de sur-type et sous-type d'entité.
Toutefois la généralisation ne peut être réalisée par héritage; l'héritage d'attributs ou d'opérations est propre à l'approche objets.
Réalisation Au niveau du référentiel, les relations entre éléments de niveaux d'abstraction différents représentent, souvent, des relations de réalisation.

Dans l'exemple ci-contre, nous voyons que la table APAB qui a été créée, par l'intermédiaire de l'outil de transformation, à partir des spécifications de l'entité APAB.De fait, la table APAB réalise l'entité APAB.

 

Diagrammes

Approche objets
UML
Approche fonctionnelle
Oracle Designer
Remarques
Diagrammes de classes Diagrammes d'entités-associations
Diagrammes logiques de données (relationnel)
Détails
Diagrammes d'objets -
Diagrammes de déploiement -
Diagrammes de composants Diagrammes de traitements (modules) Détails
Diagrammes de séquence -
Diagrammes de collaboration Diagrammes de processus
Diagrammes de flux de données
Diagrammes de hiérarchie de fonction
Détails
Diagrammes de cas d'utilisation Diagrammes de processus
Diagrammes de flux de données
Détails
Diagrammes d'états-transitions -
Diagrammes d'activités Diagrammes de processus
Diagrammes de flux de données
Détails

 

Comparaison sur la base de l'approche fonctionnelle (Merise)

Démarche

Nous avons effectué cette comparaison en nous inspirant de l'ouvrage De Merise à UML de N. Kettani, D. Mignet, P. Paré et C. Rosenthal-Sabroux publié en 1999 [KETT-98].
Au chapitre 6 de l'ouvrage, sous le titre Merise et UML en parallèle, les auteurs ont établi un comparatif  sur la base des points clés suivants:

  • les principes;
  • la modélisation du métier;
  • la modélisation du système informatique:
  • la démarche.

Nous avons développés quelques éléments significatifs, liés aux principes de la méthode Merise, en procédant de la manière suivante:

  • nous avons présenté les arguments des auteurs;
  • nous avons développé quelques arguments en nous inspirant de l'expérience de notre cas pratique.

Remarque: les auteurs ont décrit la modélisation avec UML dans une première partie; dans une deuxième partie, ils présentent la démarche d'ingénierie; enfin, dans la troisième partie ils établissent le parallélisme. Le parallélisme est proposé à partir des concepts de Merise; les concepts de Merise sont tous expliqués et comparés à ceux d'UML, implicitement d'UP lorsqu'il s'agit manifestement d'éléments méthodologiques.

Principes de Merise

[KETT-98 p 293] Cinq principes fondamentaux ont présidé à l'élaboration de Merise: l'approche systémique, les cycles de construction du système d'information, l'approche fonctionnelle, la vision duale des données-traitements et l'approche qui part du général pour atteindre le particulier.

Cycle d'abstraction

Les arguments de Kettani et consorts

[KETT-98 p 297] L'approche Merise - Le cycle d'abstraction permet de sérier les niveaux de préoccupations lors de la description ou de l'analyse du système... Les trois niveaux retenus correspondent à des degrés de stabilité et d'invariance de moins en moins élevés.

  • Le niveau conceptuel
  • Le niveau logique
  • Le niveau physique

L'approche UML - UML propose différentes notions (cas d'utilisation, paquetage, classes, composant, nœud) et différents diagrammes pour modéliser le systèmes aux différents niveaux d'abstraction.

Nos arguments

Lors du comparatif des méthodologies, nous avons déjà proposé une correspondance entre le concept de niveaux d'abstraction de l'approche fonctionnelle et les concepts de l'approche "objets".
Plus de détails

Concernant les données, ces niveaux d'abstraction de l'approche fonctionnelle ont été repris par l'approche "objets". Un atelier de génie logiciel comme Rose de Rational automatise même le passage du modèle d'entité métier à un modèle logique de données relationnel et vice-versa; le passage au modèle relationnel, sous forme de tables et de contraintes d'intégrité, permet de gérer techniquement la persistance des données d'entreprise. Les tables du modèle relationnel de Rational Rose sont en fait une spécialisation des classes.

Nous avons utilisé ce concept de niveau d'abstraction implanté par Rational Rose pour créer un modèle relationnel de données à partir de la structure de la base de données que nous avons créée par l'approche fonctionnelle; ou dit autrement, nous avons effectué une démarche d'ingénierie inverse. Ensuite, nous avons utilisé l'automate de Rational Rose de transformation des tables en classes ou plus précisément en entités métier.
Plus de détails

Pour illustrer notre propos, nous donnons ci-après les références sur les diagrammes des ventes de notre fabricant de cartes de téléphonie. Ce domaine des ventes est une partie de la modélisation des entités métiers périphériques.

Approche fonctionnelle Approche objets
Niveau conceptuel Diagramme ici Diagramme ici
Niveau logique Diagramme ici Diagramme ici

Approche fonctionnelle

Les arguments de Kettani et consorts

[KETT-98 p 298] L'approche Merise - Merise propose une approche descendante où le système réel est décomposé en activités, elles-mêmes déclinées en fonctions. Les fonctions sont composées de règles de gestion, elles-mêmes regroupées en opérations. Ces règles de gestion au niveau conceptuel génère des modules décomposés en modules plus simples et ainsi de suite jusqu'à obtenir des modules élémentaires... Les limites d'une telle approche résident dans le fait que les modules sont difficilement extensibles et exploitables pour de nouveaux systèmes.

L'approche UML - Dans UML les fonctions cèdent la place aux cas d'utilisation qui permettent de situer les besoins de l'utilisateur dans le contexte réel. A chaque scénario correspond des diagrammes d'interaction entre les objets du système et non pas un diagramme de fonction...

Nos arguments

Dans le cas de l'AGL Oracle de Designer, cette approche fonctionnelle est mise en oeuvre sous forme de processus, puis de fonctions et enfin de modules et composants.

  • Les processus sont mis en oeuvre pour la modélisation du métier; les processus peuvent se décomposer  en sous-processus dans une démarche récursive.
  • Les fonctions sont mises en oeuvre pour la modélisation des flux de données;  les processus peuvent se décomposer  en sous-processus dans une démarche récursive.
  • Les modules sont mis en oeuvre pour la conception des traitements à réaliser; les modules sont formés de composants.

Les processus et les fonctions sont des vues différentes d'éléments identiques du référentiel (les Business Functions); les processus montrent plutôt les aspects du système entreprise et les fonctions montrent plutôt les aspects du système d'information. Les Business Functions par l'intermédiaire des modèles de processus et de flux de données permettent d'exprimer les besoins métier et du système d'information.
Les diagrammes de cas d'utilisation d'UML et les diagrammes incluant des Business Functions de Designer sont relativement proche;(Montrer la correspondance des diagrammes Process/Fonctions et Use case) la différence entre UML et l'approche fonctionnelle de Designer réside dans le concept de scénarios et de diagrammes d'interaction qui sont certainement un atout important d'UML pour exprimer clairement les besoins du métier à la réalisation du système informatique.

Designer transforme automatiquement, grâce aux règles du référentiel, les fonctions en squelette de modules et composants; le concepteur affinera la spécification des modules à partir des besoins exprimés dans les fonctions et leurs hiérarchies de sous-fonctions.

Les composants de modules manipulent les tables ou vues du modèle relationnel de données; ces composant peuvent être spécifiques à un module ou être indépendants et donc réutilisables dans tout module.
L'essentiel des spécifications des modules et composants sont indépendants de l'environnement d'exécution; de ce fait, les générateurs de code de Designer sont capables de créer le code pour de multiples langages de programmation.

Schéma de synthèse

Ainsi, même si Designer s'appuie sur le concept d'analyse fontionnelle, il offre de solides mécanismes de réutilisation, d'extensibilité et d'indépendance de plate-forme d'exécution.

Approche données-traitements

Les arguments de Kettani et consorts

[KETT-98 p 298] L'approche Merise - Merise propose de considérer le système réel selon deux points de vue: un point de vue statique (les données), un point de vue dynamique (les traitements). Il s'agit d'avoir une vision duale du système réel pour bénéficier de l'impression de relief qui en résulte, et donc consolider et valider le système final.

L'approche UML - L'approche objet associe les informations (données ?) et les traitements. De cette façon, elle assure un certain niveau de cohérence

Nos arguments

Comme nous l'avons déjà expliqué lors de la comparaison des deux approches méthodologiques, il nous semble qu'actuellement cette dualité ne doit plus être comprise dans une vision stricte des deux termes.

Nous relevions entre autres que:

Les MCD, sous formes entités et associations, incluent les éléments statiques de définition des données; progressivement, ils ont été enrichis pour supporter des règles d'intégrité de données; ces règles d'intégrité ajoutent une responsabilité qu'il n'est pas nécessaire de modéliser par un traitement spécifique.

Les MLD, sous forme de modèles relationnels de Codd, incluent les éléments statiques sous forme de tables et de colonnes; tout comme les MCD, ils ont été enrichis pour supporter des règles d'intégrité. Mais en plus, les tables ont été dotées de déclencheurs, triggers; ces déclencheurs réagissent lors de la manipulation d'enregistrements et donnent ainsi une dimension dynamique ou comportementale aux tables.
Les tables endossent donc de véritables responsabilités de service au bénéfice du couple données/traitements.

Pour illustrer notre propos, nous reprenons les modèles de niveau logique du domaine des ventes de notre fabricant de carte de téléphonie.  Nous reproduisons ci-dessous, la table VENTES du modèle logique des deux approches.

Approche fonctionnelle
Oracle Designer
Approche objets
Rational Rose
 

 

Nous pouvons observer la représentation similaire des deux constructeurs:

  • Une première zone pour le nom de la table;
  • Une deuxième zone pour l'aspect statique: colonnes ou attributs;
  • Une troisième zone pour les contraintes.

Pour l'approche objet, avec Rational Rose, la table VENTES est une classe particulière; les contraintes sont représentées en tant qu'opérations stéréotypées du nom du genre de contrainte qu'elles réalisent.
Nous voyons clairement, par cet exemple, le lien entre contraintes de tables du modèle relationnel de Codd et les opérations de l'approche objets. A notre sens ce lien confirme que la dualité données/traitements, de l'approche fonctionnelle, ne doit pas être appliquée de manière stricte.

 

Néanmoins la dualité, dans une vision large du terme, reste un concept essentiel de l'approche fonctionnelle et est également appliquée en approche objets pour l'analyse.
En approche fonctionnelle, avec Oracle Designer cette dualité se retrouve au niveau conceptuel et au niveau logique.
Au niveau conceptuel, les spécifications des fonctions incluent l'utilisation des entités et des attributs, ainsi que les manipulations autorisées.
Voir la fonction Enregistrer annonce client
Au niveau logique, les spécifications des composants de modules incluent l'utilisation des tables et des colonnes ainsi que les manipulations autorisées.

Nous reproduisons ci-dessous, une vue partielle du module GB10 - Enregistrer annonce client; nous voyons le composant APAB et son utilisation des tables APAB, PRODUITS et HISTOFWS.

Nous montrerons, dans la phase 5 de complémentarité ou de couplage des deux approches, les liens très forts que nous pouvons établir entre le modèle logique de traitements d'Oracle Designer et le modèle d'analyse d'UP basé sur les stéréotypes "entité", "contrôle" et "frontière".
De manière très synthétique nous explorerons les liens ou correspondances suivantes:

Approche fonctionnelle
Modèle logique de traitement
Approche objets
Modèle d'analyse

Module 

Contrôle
+
Frontière
Composant Frontière
+
Contrôle
Utilisation de table Entité

 

Comparaison sur la base des diagrammes UML

[KETT-98 p 20] Un des aspects fondamentaux d'UML qui déroutent souvent les non-initiés est le fait qu'un diagramme n'est pas un modèle mais une représentation graphique de quelques éléments du modèle.

A notre sens, la séparation modèle et diagramme n'est pas lié à un langage de modélisation mais à la mise en place d'un AGL doté d'un référentiel; le référentiel enregistre l'entier du ou des modèles, les diagrammes sont des objets du référentiel qui restituent graphiquement une vue particulière de tout ou partie du modèle.

Nous voyons dans l'exemple ci-dessus, le diagramme ANALYSER ANNONCE CLIENT-INITIAL et les relations de d'inclusion (dépendance en UML) des éléments qu'il présente.
Vue du diagramme

Diagrammes de structure

Diagrammes de classes

Les diagrammes entités-associations sont un sous-ensemble des diagrammes de classes; ils représentent un domaine sous forme d'objets métier.
Plus de détails

Pour illustrer notre propos, nous donnons ci-après les références sur les diagrammes des ventes de notre fabricant de cartes de téléphonie. Ce domaine des ventes est une partie de la modélisation des entités métiers périphériques.

Plusieurs auteurs ont déjà montré la forte concordance existants entre ces diagrammes et les concepts qu'ils montrent; nous proposons la lecture des deux ouvrages suivants:

Diagrammes d'objets

Les diagrammes d'objets n'existent pas avec Oracle Designer.

Diagramme de déploiement

Les diagrammes de déploiement n'existent pas avec Oracle Designer.

Diagrammes de composants

Les diagrammes de composants n'existent pas sous cette forme ou sous ce nom; mais les diagrammes de modules (modèle logique de traitement) remplissent ce rôle de visualisation de composants.

Un module est spécifié pour un environnement d'exécution, propriété Language. A partir de cette propriété le générateur de module créée les composants utiles et nécessaires en fonction du langage de génération choisi.

Dans l'exemple ci-dessus, le module GB10 est spécifié pour Web PL/SQL; le générateur de code créera automatique les paquetages (modules) PL/SQL définis par les règles du modèle de génération. En l'occurrence, il s'agit des 3 paquetages ci-contre.
  • Le paquetage GB10$ est la matérialisation sous forme de code, du composant ( terme UML) représentant le module GB10.
  • Le paquetage GB10$APAB est la matérialisation sous forme de code, du composant APAB ( terme UML et Designer) inclus ou utilisé par le module APAB.
  • Le paquetage GB10$JS$APAB est la matérialisation sous forme de code, du composant de fonctions de service Javascript pour l'interface utilisateur Web de gestion du composant APAB.

Nous montrons ci-dessus, la réalisation de l'interface du module GB$10; en particulier, la procédure Startup qui permet aux utilisateurs finaux d'accéder aux services du modules.

Le même module peut être généré pour un autre langage, par exemple Visual Basic; dans ce cas, le générateur de code créera les composants Visual Basic également définis par les règles du modèle de génération.
Plus de détails

Diagrammes de comportement

Diagrammes de séquence

Les diagrammes de séquences n'existent pas avec Oracle Designer. Toutefois, les diagrammes de processus peuvent être paramétrés et activés pour simuler le déroulement des étapes d'un processus.
Grâce à ce mécanisme, les diagrammes de processus peuvent être utilisés en tant que scénarios de processus tout comme les diagrammes de séquences représentent les scénarios ou l'instantiation de cas d'utilisation.

Ci-dessus, nous avons reproduit un extrait de l'écran de simulation de notre processus de gestion des bugs. La simulation doit se faire depuis le client Window de Designer, de ce fait, nous ne pouvons l'illustrer. 

Les différentes simulations ou les multiples scénarios se mettent place en modifiant les propriétés des éléments constitutifs du diagramme: processus, flux, entrepôt...

Dans l'exemple ci-dessus, nous montrons les propriétés d'un flux; nous pouvons observer le cadre Logic qui nous permet de paramétrer les conditions de combinaison de flux.

Diagrammes de collaboration

Les diagrammes de collaboration n'existent pas avec Oracle Designer. Toutefois, les diagrammes de processus et de flux de données montrent aussi comment les sous-processus ou les sous-fonctions "collaborent" pour "réaliser" les services du processus ou de la fonction dont ils sont des étapes ou des parties.

Pour illustrer notre propos, nous donnons ci-après les références sur les diagrammes relatifs à l'enregistrement de l'annonce d'un client au niveau des besoins et de l'analyse.

Approche objets Approche fonctionnelle
Diagramme de collaboration des objets d'analyse Diagramme de processus

Remarque: Nous n'avons pas réalisé le diagramme de sous-fonctions.

De son côté, le diagramme de hiérarchie montre de façon très synthétique l'ensemble des sous-fonctions qui "collaborent" à la réalisation d'une fonction de niveau supérieur.

 

Diagrammes de cas d'utilisation

Les diagrammes de processus et de flux de données ont de nombreuses similitudes avec les diagrammes de cas d'utilisation.

Pour illustrer notre propos, nous donnons ci-après les références sur les diagrammes relatifs au système de gestion des bugs dans son ensemble.

Approche objets Approche fonctionnelle
Diagramme de cas d'utilisation Diagramme de processus

Diagramme de flux de données

  • Les fonctions ou processus peuvent être assimilés aux cas d'utilisation.
  • Les responsabilités des diagrammes de processus ou les entités externes des diagrammes de flux de données peuvent être assimilés aux acteurs.
  • Les relations entre cas d'utilisation se retrouvent, probablement, dans les concepts de flux conditionnel pour la relation d'extension et de fonction globale pour la relation d'inclusion mais, ceci mériterait d'être vérifié.

Diagramme d'états-transitions

Les diagrammes d'états-transitions n'existent pas avec Oracle Designer.

Diagrammes d'activités

Les diagrammes de processus et de flux de données ont de nombreuses similitudes avec les diagrammes d'activité.

Pour illustrer notre propos, nous donnons ci-après les références sur les diagrammes relatifs au système de gestion des bugs dans son ensemble.

Approche objets Approche fonctionnelle
Diagramme d'activités (Workflow global) Diagramme de processus

Diagramme de flux de données

  • Les fonctions ou processus peuvent être assimilés aux activités.
  • Les responsabilités des diagrammes de processus ou les entités externes des diagrammes de flux de données peuvent être assimilés aux responsabilités.
  • Les flux et les conditions déclenchent également des transitions.

 

Conclusion

A faire...

 

[KETT-98 p 3] L'approche objet est associée à la modélisation du système d'information en couches qui permet de sérier et hiérarchiser les préoccupations de l'entreprise. Chaque niveau bénéficie des services de la couche inférieure et propose les siens à la couche supérieure. UML permet le découpage du système d'information de l'entreprise en deux: le système métier et le système informatique.

  • Le système métier constitue la modélisation de l'activité selon une vision externe et une vision interne. Il décrit les aspects statiques et dynamiques de l'activité à un haut niveau d'abstraction en ignorant les "détails" de l'implémentation technique et donc informatique.
  • Le système informatique recouvre la partie du système métier qui donne lieu à automatisation. Il résulte de la concrétisation des choix effectués parmi les possibilités offertes par les technologies. Sa modélisation fournit une image de l'activité des utilisateurs au niveau opérationnel et au niveau physique.

[KETT-98 p 106] L'encapsulation permet de rendre les structures et les objets indépendants les uns des autres... Le système est la résultante d'un assemblage d'objets qui coopérent et non plus un système global dont il faut maîtriser le comportement dans les moindres détails. Par ailleurs, l'approche objet intègre naturellement les données et les traitements. Or, toutes les approches existantes d'élaboration d'architecture passent par une phase de croisement entre les données et les traitements. Ce croisement peut prendre plusieurs formes... Certaines version de Merise ou l'IIE de J. Martin mettent en oeuvre des matrices données-traitements. Enfin, SSAD/M utilise les modèles fonctionnels (diagramme de flux de données).