Discussion :

[OSryx]

Bonjour,

Supposons que je développe une application bureau avec Java SE, suivant le modèle de développement Cycle-V. J'ai terminé la rédaction du cahier des charges de ma future application , j'y ai exprimé les fonctionnalités du système ainsi que l'ensemble du besoin (fonctionnel et non-fonctionnel) du client. J'ai établit ce que l'application idéal fera dans un document que je peux appeler *User Requirements document*.

Maintenant, je passe à la conception de l'architecture de l'application ainsi que la conception détaillée. Cette partie je ne comprends pas en quoi elle consiste ?

L'idée que j'ai est comme suit : d'abord je mets au point un diagramme des cas d'utilisation, et pour chaque cas d'utilisation je mets au point un diagramme de séquence, pour qu'enfin je réalise un diagramme des classes. Ce dernier me permettra de générer du code source de base.

Est ce que c'est correct ? Et au sujet du système de gestion de base données, je le fais intervenir à quel stade de la conception ?

Toute aide est la bienvenue :)

[CinePhil]

Et au sujet du système de gestion de base données, je le fais intervenir à quel stade de la conception ?

L'application utilise la base de données mais ce n'est pas l'application qui détermine (et/ou modifie) la structure de la base de données.
Il faut donc commencer par concevoir la BDD.

Le diagramme de classes UML peut être utilisé pour faire le schéma de la BDD mais je préfère pour ma part la rigueur du modèle conceptuel de données (MCD) de la méthode Merise.

Si vous n'avez pas l'habitude de cette partie de la conception, commencez par écrire les règles de gestion des données et le MCD sera plus facile à dessiner ensuite.

On peut vous aider pour cette étape dans le forum Schéma.

Bon courage.

[autran]

Comme tu parles de java SE je suppose que tes interfaces seront en SWING. Ce qui déjà regle le probleme de ton interface graphique et du MVC.

Passons à la partie modélisation de tes objets metier. Car c'est bien ces objets metier qui seront dans tes diagrammes de classes. Je pense pour ma part que tu devrais en premier lieu concevoir un diagramme de classes pour ces objets metier, puis tu les mettras en persitence dans la base de données via un ORM de ton choix. du coup pour le MCD de ta base ce sera juste le diagrammes de classes sans les methodes.

Donc pour moi ton architecture sera :

• couche présentation : Swing hebergé sur le poste client
• couche metier : java SE hebergé sur le poste client
• couche persitence :
  
  • ORM de ton choix (JDBC ...) hebergé sur le poste client
  • base de données hebergé ou tu veux (client ou serveur)

si tu avais fait un truc à la sauce web avec JSF EJB .... ton architecture aurait été plus complexe.

bon courage pour la suite

[CinePhil]

Je pense pour ma part que tu devrais en premier lieu concevoir un diagramme de classes pour ces objets metier, puis tu les mettras en persitence dans la base de données via un ORM de ton choix.

Un Objet Réellement Merdique ? Beurk !

Mettre directement les classes de l'application dans la BDD, c'est introduire des redondances dans la BDD et donc potentiellement ouvrir la porte aux données incohérentes.

La démarche la plus sérieuse consiste à :
1) Concevoir la BDD
MCD puis MLD.

2) Concevoir le diagramme de classes de l'application

3) Déduire du diagramme de classes ce que j'appelle, pour revenir à Merise, un Modèle Organisationnel des Données (MOD) qui déterminera les vues à réaliser dans la BDD.

4) Développer l'application en faisant en sorte que les classes interrogent les vues de l'application et non pas directement les tables.
Certaines vues permettront, selon le SGBD et selon leur structure, directement de modifier les données (autoriseront les requêtes INSERT, UPDATE, DELETE). Pour les autres vues, il faudra développer des procédures SQL qui seront appelées par l'application pour la modification des données.

Du coup, plus besoin d'Objet Réellement Merdique.

[Oppenheimer]

Bonjour Osryx,

Il me semble qu'il y a deux points de vue opposés, je me propose donc de trancher le noeud (sans toutefois faire un impair, vu qu'on est trois intervenants).

-Je vais dans le même sens que CinePhil.

Mais avant de détailler, revenons sur ce qui "oppose" l'approche objet et une méthode basée sur le monde relationnel (structuré, si vous préférez) comme la méthode Merise.

À mon sens, la modélisation UML a pris le contre-pied de Merise. Merise est très rigoureux, mais qui dit rigueur, dit rigide. Ce n'était du coup pas toujours exploitable pour des entreprises pré-existantes. Je ne suis par contre pas spécialiste de UML, mais vu d'ici, UML a un peu pris le contre-pied, en se proposant un concept qui n'en est pas un - celui d'"objet".

On retient souvent Merise pour la partie des données - statique - mais cette méthode a aussi proposé d'explorer la partie traitements - dynamique - qui est souvent omise, pour deux raison: en pratique, à cause de cet aspect rigoureux, et en théorie, parce que cette partie de Merise est plutôt... indigeste (c'est quasi-illisible, en tout cas pour moi).

Toujours est-il que sur un plan conceptuel, on comprendra bien que les données étant la partie plutôt statique, l'approche en cascade de Merise est tout dédiée. Cette approche en cascade veut dire que la conception doit être "parfaite", et ne peut être re-négociée à partir de l'implémentation (pas de retour sur la conception), ou alors, il faut tout recommencer.

Concrètement, il vous faut établir un Modèle Conceptuel de Données, en distinguant les entités-types différentes. Une entité-type, c'est en quelque sorte le correspondant des classes en UML. En gros: les substantifs que vous distinguez dans votre problématique.

Ces entités sont ensuite liées entre elle par une notion qui dit bien ce qu'elle veut dire: l'association. Alors qu'une entité est - donc - un substantif, les association sont des verbes infinitifs. Par exemple, comme association entre une personne et un livre-type, j'ai plusieurs associations possibles (commenter, écrire - éventuellement emprunter si l'on distingue le livre-type en livre-objet (distingué non plus par son ISBN, mais par sa cote)).

Ces associations peuvent généralement avoir des attributs - à vous de voir lesquels sont pertinents, mais sachez qu'elles ont aussi une clé identifiant (clé candidate).

-Ce n'est pas fini: Il faut ensuite traduire ce MCD en Modèle Logique de Données. Et là, ça se corse légèrement (en gros, il y a encore des truc à faire).
Les associations (verbes) deviennent des entités (substantifs, donc respectivement aux exemples d'avant: commentaire, écriture, voire emprunt).

Dans le MLD, les relations (liens) présentant potentiellement pour cardinalités maximales des cas de "plusieurs-à-plusieurs" (p. ex.: (1;n)-(1;n)) doivent être scindées, par une nouvelle entité intercalaire.

Dans le cas spécial des emprunts, on peut avoir plusieurs emprunts par personne, mais dans un cas très générique (selon comment l'emprunt est identifié), on pourrait aussi avoir "plusieurs personnes par emprunt".

Dans ce cas, on se tord pas trop la tête, on insère une table: t_personne_emprunt, où typiquement, j'aurai deux attribut, chacun une clé étrangère pointant respectivement sur t_personne ainsi que sur t_emprunt, et la composition des deux clé étrangères donne une clé primaire.

C'est à peu près tout.
Différences principales à tenir en compte dans le passage du MCD au MLD:

• les entités-types du MCD s'appellent tables dans le MLD;
• le MCD lie les entités sans se soucier du détail, alors que le MLD présente les liens entre attribut clé (primaire) et attribut-clé (étrangère) (de la table correspondante).

Vous trouvez facilement une demi douzaine de règles principales sur internet, pour effectuer ce passage en tout quiétude:
-De la Haute école ARC Neuchâtel-Berne-Jura (
http://lgl.isnetne.ch/modelisation-2...d_prescplt.pdf
).
-Pensez aussi à consulter l'excellent cours de Laurent Audibert, disponible sur DVP (dites-moi, si vous ne trouvez pas).
-Enfin, je crois savoir qu'il existe une approche UML des données, faite par un Roy Gilles. J'avais imprimé le Pdf, mais ne l'ayant finalement pas lu, je ne m'en porte pas garant.

Souvenez-vous enfin qu'UML n'est pas une méthode, c'est un langage.

En espérant avoir pu vous aider.

[autran]

OSryx,

Quel ORM utilises-tu ?
Car si par exemple tu prends des EJB alors on aura une superposition à 80% entre le diagramme de classes et le MCD

Pour cinephil, je suis trop jeune pour avoir connu Merise mais il me semble bien que le MCD est sans rapport avec la base de donnée car à ce stade on est pas certain d'informatiser le SI
Il me semble meme que le diagramme idoine pour la BDD soit le MPD.
De plus chef de projet merise et très experimenté (au moins 50 ans) sur DVP m'a dit qu'on passait facilement de merise à UML pour peu que l'on soit assez agile pour fondre un MCD et un MOT dans un diagramme de classe.

Avec tout le respect dû à mes 2 grands ainés merisiens.

Kevin

[Oppenheimer]

Pour cinephil, je suis trop jeune pour avoir connu Merise mais il me semble bien que le MCD est sans rapport avec la base de donnée car à ce stade on est pas certain d'informatiser le SI

Bonjour Kevin,
Je n'ai pas très bien compris: le "stade" de UML, ou de Merise?
-Pour une modélisation en général - et plus particulièrement Merise - modéliser avant réalisation su système informatique, cela tombe un peu sous le bon sens...

Il me semble meme que le diagramme idoine pour la BDD soit le MPD.

Le Modèle Phyisque de Données ne veut pas dire grand chose, pour être honnête: il ne s'agit que de la représentation du Modèle Logique dans le système choisi.

De plus chef de projet merise et très experimenté (au moins 50 ans) sur DVP m'a dit qu'on passait facilement de merise à UML pour peu que l'on soit assez agile pour fondre un MCD et un MOT dans un diagramme de classe.

Mon Dieu, les Traitements, il faut que je m'y colle à coups de pieds au... je n'y suis que débutant, je ne peux donc pas confirmer. Mais vu de chez moi ce sont des vues aussi complémentaires (et contradictoires) que la dualité onde-corpuscule... Aucune n'est fausse, mais elles ne peuvent pas se "confondre".
Par contre, sur la généralité, oui, conceptuellement, toute modélisation peut être traduite en une autre (pour autant qu'elles aient la même profondeur sémantique). Il existe même des outils objet-relationnel permettant de faire l'équivalence.

Avec tout le respect dû à mes 2 grands ainés merisiens.

[autran]

Openheimer,
à ce stade signifie que :
dans une lointaine galaxie en 85 par là (d'après un JEDI qui me l'a compté) tu te servais de la methode merise pour analyser un besoin que tu modélisais avec des diagramme et que jusqu'à un certain stade tu ne savais pas si le besoin recevrait une réponse organisationnelle ou que tu ferais une base de données et qu'en ces temps reculés tu faisait des MPD que tu donnais à des DBA qui connaissaient le secrets des bases de données relationelles maintenant disparues et qui tournaient sur des serveurs très chers en mode console.....

puis il y eu la guerre noire et maintenant :
Linux est graphique
mysql est gratuit et graphique comme linux
et quant on a un besoin on sait que l'on fera forcement une appli souvent Web
en plus on fait de l'agile en UML et on s'echange plus que des diagramme de classes

que la force soit avec vous !

Luke Skywalker

[Oppenheimer]

Lol,

Mais on transmet au plus des MLD aux DBA, vu que le MPD est la partie spécifique (qui peut être plus ou moins délirante par rapport à la convention de modélisation); (ce seraient dans ce cas-ci les DBA qui feraient le MPD).

Je ne vois pas en quoi l'arrivée de MySQL graphique change quelque chose au relationnel (N. B.: je n'ai presque jamais fait de DB en mode console - sauf respectivement sur papier ou en non relationnel).

-Par contre, je méprise un peu les aspects web (attention: pas ceux qui s'en chargent) - on dit qu'on fait un truc nouveau et partagé, et généralement la cohérence est perdue.

Mais je suis conscient que sur le plan théorique, le théorème PACELC montre que la cohérence (consistance) peut être sauvée.

À part ça, l'agile me parle un peu - j'ai vu les propriétés BASE des keyspaces, s'opposant aux propriétés ACID des bases relationnelles.

N. B.:
Je vous donne l'impression d'être vieux, mais j'ai 31 ans, lol. Je n'engage pas de politique en faveur de Merise - je ne l'évoque que parce que c'est elle que j'ai apprise, et l'équivalence relationnel-objet reste possible.

[CinePhil]

Wow ! Il y a du lourd, là !

Cette approche en cascade veut dire que la conception doit être "parfaite", et ne peut être re-négociée à partir de l'implémentation (pas de retour sur la conception), ou alors, il faut tout recommencer.

Euh... pourquoi TOUT recommencer ?
S'il y a une modification des besoins, on traite la modification en ne touchant à la conception que de ce qui est nécessaire. Que ce soit avec la méthode et les modèles merisiens ou avec des diagrammes UML, le traitement de la modification est similaire.
Un MCD - et le MLD qui en découle - est la traduction d'un besoin à un instant T. Si le besoin change à T+x, on fait une version v+x des modèles de données.

Une entité-type, c'est en quelque sorte le correspondant des classes en UML

En quelque sorte... par extension, l'équivalent du MCD merisien est le diagramme de classes UML.

Les associations (verbes) deviennent des entités (substantifs, donc respectivement aux exemples d'avant: commentaire, écriture, voire emprunt).

C'est un peu trop généraliste d'écrire ça ! Voir mon billet de blog pour savoir quand une association du MCD engendrera la création d'une table dans le MLD puis dans la base de données.

Dans le MLD, les relations (liens) présentant potentiellement pour cardinalités maximales des cas de "plusieurs-à-plusieurs" (p. ex.: (1;n)-(1;n)

Les cardinalités sont représentées dès le MCD.
Exemple :
Personne -0,n----travailler----0,n- Projet

le MCD lie les entités sans se soucier du détail

Faux ! Voir exemple ci-dessus, en format texte, où le "détail" des cardinalités est déjà présent. Sur un MCD fait avec un logiciel de modélisation (ou au crayon, à la main), on représente bien l'entièreté de l'entité-type avec ses propriétés. On peut même déjà typer ces propriétés (entier, varchar, date...) et représenter la clé de l'entité-type en la soulignant ou en lui collant le symbole d'une clé.

Souvenez-vous enfin qu'UML n'est pas une méthode, c'est un langage.

Vrai ! Dans l'absolu, on peut tout à fait respecter la méthode Merise en utilisant les diagrammes UML et non pas les modèles merisiens.

Car si par exemple tu prends des EJB alors on aura une superposition à 80% entre le diagramme de classes et le MCD

Et c'est dans les 20% que se trouveront les problèmes futurs !

je suis trop jeune pour avoir connu Merise

Jeune à quel point ? J'ai étudié Merise au CNAM en 2006, je crois. Ce n'est pas si vieux.

il me semble bien que le MCD est sans rapport avec la base de donnée

Le MCD est indépendant de la solution de stockage des données qui sera implémentée. De là à dire que c'est sans rapport, c'est un peu exagéré !

Il me semble meme que le diagramme idoine pour la BDD soit le MPD

Dès le MLD, on a fait 90% du boulot pour implémenter la future base de données. Les (bons) logiciels de modélisation sont capables de traduire le MLD en code SQL à donner à manger au SGBD choisi.

De plus chef de projet merise et très experimenté (au moins 50 ans) sur DVP m'a dit qu'on passait facilement de merise à UML pour peu que l'on soit assez agile pour fondre un MCD et un MOT dans un diagramme de classe.

À condition, en effet, d'avoir assez d'expérience pour ne pas sacrifier la rigueur merisienne aux facilités permises par le diagramme de classes.

des DBA qui connaissaient le secrets des bases de données relationelles maintenant disparues

Euh... disparues, les bases de données relationnelles ?
Le présent forum se sert d'une BDDR ! Tout comme un nombre considérables de logiciels de gestion et de sites webs sur notre bonne vieille planète quelconque en bordure de galaxie.

Linux est graphique

Mouais... disons plutôt que Linux est muni d'interfaces graphiques (KDE, Gnome...).

mysql est gratuit

Faussement gratuit, sous certaines conditions en fait.
Par contre, Postgresql est gratuit.

et graphique comme linux

Là encore, c'est un abus de langage ! On utilise un logiciel graphique (MySQL Workbench, phpMyAdmin, par exemple) pour gérer MySQL. Mais MySQL reste bel et bien un SGBD en mode texte.

quant on a un besoin on sait que l'on fera forcement une appli

Croyez-vous vraiment qu'on se lançait avant dans une conception détaillée sans avoir envisagé qu'il y aurait le développement d'une application derrière ?

La méthode Merise commence au Schéma directeur des systèmes d'informations (SDSI). Il revient ensuite de sélectionner et de prioriser les besoins exprimés dans le SDSI pour lancer les projets qui sont, pour la plupart, des projets d'informatisation, donc de développement logiciel (ou d'implémentation dans l'organisme de solution existantes) avec ou sans base de données, relationnelle ou non.

que la force soit avec vous !

Par Maître Yoda, inspiré, je suis, tous les jours car en fond d'écran de mon ordinateur, il me regarde.

Tu as encore beaucoup à apprendre, padawan... moi aussi d'ailleurs... la voie du Jedi est un apprentissage permanent. Surtout en informatique.

[CinePhil]

Encore une chose pour préciser ma pensée...

Je reconnais volontiers que le développement en POO est un grand progrès par rapport aux anciennes manières de développer du logiciel mais le défaut des développeurs en POO est souvent de négliger la rigueur dans la maîtrise des données et de considérer parfois, voire souvent, le SGBD comme une bibliothèque fourre tout où l'on stocke des données et qu'on peut assez facilement retrouver avec une bête requête SQL SELECT.

Ça engendre parfois des monstres qui en grossissant deviennent tout à fait contre performants, tout simplement parce que le modèle de données a été mal conçu. Alors viennent les lenteurs à l'interrogation de la BDD alors que tout allait très vite à la création de la BDD et au début de la montée en charge. Alors viennent aussi les résultats statistiques bizarres et en fait faux parce les données sont incohérentes, redondantes, mal enregistrées...

La plupart, sinon tous les logiciels web open source que j'ai un peu analysés ont un modèle de données foireux. Ça fonctionne plus ou moins bien parce que le logiciel se charge de bien des choses qui seraient plus performantes si elles étaient réalisées par le SGBD. Je peux inclure dans cette liste noire les CMS (Drupal, Joomla, Worpress..), des outils apparemment plus sérieux, plus professionnels tels que Jira, Moodle, GLPI...

Bref, j'arrête là ; ma fille m'attend.

[Oppenheimer]

Mais c'est plus un troll, c'est une Armée ! (Je cite un camarade de presence-pc.)

Wow ! Il y a du lourd, là !

Euh... pourquoi TOUT recommencer ?
S'il y a une modification des besoins, on traite la modification en ne touchant à la conception que de ce qui est nécessaire.

Vous le mentionnez vous-même: S'il y a une modification des besoins.

Que ce soit avec la méthode et les modèles merisiens ou avec des diagrammes UML, le traitement de la modification est similaire.

Dans cette phrase, vous confondez modèle et méthode. La "philosophie", si vous préférez, de Mersie est en cascade - je gagerais ma main au feu.

Un MCD - et le MLD qui en découle - est la traduction d'un besoin à un instant T. Si le besoin change à T+x, on fait une version v+x des modèles de données.

Merci pour ce contre-exemple célèbre. C'est la cause de 75% de échecs de projets (vous savez, l'histoire du cahier des charges que l'on re-négocie après coup). Je ne me porte pas garant à l'unité près, mais l'excellent livre de Laurent Audibert l'explique très bien !

En quelque sorte... par extension, l'équivalent du MCD merisien est le diagramme de classes UML.

-Vous apprenez vite !

C'est un peu trop généraliste d'écrire ça ! Voir mon billet de blog pour savoir quand une association du MCD engendrera la création d'une table dans le MLD puis dans la base de données.

-Remettons-nous dans le contexte où je m'adresse à quelqu'un qui semble découvrir Merise pour la première fois, et qui est le nôtre; je n'ai fait que parler des grandes généralités !
Ceci dit, j'ai placé trois liens, ou plutôt deux avec une référence textuelle, extrêmement clairs - dont le premier est on-ne-peut-pls explicite! Merci toutefois pour votre billet, j'irai voir ça.

Les cardinalités sont représentées dès le MCD.
Exemple :
Personne -0,n----travailler----0,n- Projet

Mais je n'ai jamais dit le contraire, si vous lisez bien. J'ai seulement signifié qu'une anomalie au sujet des cardinalités pouvait demeurer lors de la première spécification d'un MLD non corrigé - mais ça semble vous avoir échappé.

Faux ! Voir exemple ci-dessus, en format texte, où le "détail" des cardinalités est déjà présent. Sur un MCD fait avec un logiciel de modélisation (ou au crayon, à la main), on représente bien l'entièreté de l'entité-type avec ses propriétés.

Ecoutez: mettez des lunettes, si l'écran vous fait mal aux yeux. Je mentionnais "lie", je parlais donc de la liaison; où l'on lie les entités sans lier les attributs spécifiquement. Je reconnais que j'ai été assez bref là-dessus, mais en gros, on tire un trait entre les "carrés", si vous préférez, sans se soucier de si la hauteur de la terminaison se trouve en face du bon attribut.

On peut même déjà typer ces propriétés (entier, varchar, date...) et représenter la clé de l'entité-type en la soulignant ou en lui collant le symbole d'une clé.

Faux! (en terme de convention, bien-entendu). Vu qu'on se trouve alors dans la... conception, le type des attributs, non seulement est de faible intérêt, mais risque de noyer le concept avec des détails "irrelevants" (comme le disent si bien les Anglais).

Vrai ! Dans l'absolu, on peut tout à fait respecter la méthode Merise en utilisant les diagrammes UML et non pas les modèles merisiens.

Ah, merci!

[Oppenheimer]

Encore une chose pour préciser ma pensée...

Je reconnais volontiers que le développement en POO est un grand progrès par rapport aux anciennes manières de développer du logiciel mais le défaut des développeurs en POO est souvent de négliger la rigueur dans la maîtrise des données et de considérer parfois, voire souvent, le SGBD comme une bibliothèque fourre tout où l'on stocke des données et qu'on peut assez facilement retrouver avec une bête requête SQL SELECT.

+1

[autran]

Salut les JEDI et seigneurs des SITHS (Systeme d'Information Technologiques Hautement Sophistiqués)

Quand j'évoque la méthode UML, c'est un abus de langage et je sais parfaitement que c'est une notation, mais ce que j'entends par là c'est les methodes de types UP qui lui sont ratachées.

Et dans 90% des cas en UP on n'echange des modélisations qu'autour des diagramme de classes. Quand un developpeur veut savoir comment mettre en persitence un objet metier, il cherche la table qui correspond. Moi c'est ce que je fait tous les jours. Parce que le developpeur a lui meme créé la base de données.

Quant au CNAM, je viens de faire il y a 2 ans des UV de commerce electronique et de modélisation, programme sisponible ici : http://formation.cnam.fr/par-ecole/e...n-208599.kjsp?
J'y ai fait de l'UML plein pot 6 mois sur 7. Le septieme mois c'était l'implémentation du projet UML en JAVA avec la base de données générée a partir du diagramme de classes dans Eclipse.

Car aujourd'hui un developpeur d'appli web est bien souvent analyste developpeur et dba. dans ma SSII pour faire cela je suis vendu au client comme ingénieur d'étude ou developpeur full stack

[ZenZiTone]

Faux! (en terme de convention, bien-entendu). Vu qu'on se trouve alors dans la... conception, le type des attributs, non seulement est de faible intérêt, mais risque de noyer le concept avec des détails "irrelevants" (comme le disent si bien les Anglais).

+1 ! Le problème c'est que les logiciels de conception le permettent...

[Oppenheimer]

Quand j'évoque la méthode UML, c'est un abus de langage et je sais parfaitement que c'est une notation, mais ce que j'entends par là c'est les methodes de types UP qui lui sont ratachées.

Et dans 90% des cas en UP on n'echange des modélisations qu'autour des diagramme de classes.

-Kevinternet, je vous crois. Mais quand je pense à l'excellent livre, de Laurent Audbert encore une fois - mais cette fois pas celui de SQL mais celui de UML - où je vois la richesse des différents types de modèles en UML, n'en exploiter qu'un dans 90% des cas me fait presque mal au coeur.

[CinePhil]

Sur les quelques projets de développement que j'ai eu à réaliser, nous avons utilisé :
1) La MCD merisien dérivé ensuite en MLD pour la conception de la BDD
2) Le digramme de cas d'utilisation UML pour décrire les principaux flux de l'application
3) Parfois des digrammes d'état UML.
4) Des "fiches de spécification" décrivant en détail les cas d'utilisation :
- un tableau donnant les acteurs, la fréquence d'utilisation, la criticité, les pré-conditions et les post-conditions
- la description des opérations sous forme d'allers-retours entre homme et machine ;
- la liste des règles de gestion ;
- la liste des cas d'exceptions à traiter.

Ce dernier outil était très pratique pour préparer et dérouler les tests.

Je le répète : le MCD reste, selon moi, le meilleur outil pour concevoir correctement une BDD. Le reste des modèles merisiens peut être remplacé par les diagrammes UML.

[autran]

Kevinternet, je vous crois. Mais quand je pense à l'excellent livre, de Laurent Audbert encore une fois - mais cette fois pas celui de SQL mais celui de UML - où je vois la richesse des différents types de modèles en UML, n'en exploiter qu'un dans 90% des cas me fait presque mal au coeur.

Tout à fait correct Oppenheimer. Mais dans un projet ou l'on travaille ensemble, on doit prendre comme element d'interop ce que tout le monde connait et maitrise. Et aujourd'hui c'est déjà bien quand dans un projet tout le monde maitrise un modèle meme si il en existe d'autres.

je crois qu'une des créatrice de Merise en 83 (j'étais pas né et ma mere était encore à l'école) disait :

• 10% des informaticien ont entendu parler de merise.
• sur ces 10%, 10% ont entendu parler de MCD
• sur ces 10% de 10%, 10% seulement savent faire un MCD correct

ben c'est pareil en UML, 0.1% savent comprendre ou faire un diagramme de classe alors si en plus il fallait utiliser les diagramme de sequence d'état transition .... on aurait une équipe de projet par nation.

[ZenZiTone]

ben c'est pareil en UML, 0.1% savent comprendre ou faire un diagramme de classe alors si en plus il fallait utiliser les diagramme de sequence d'état transition .... on aurait une équipe de projet par nation.

Ouais, m'enfin ce sont des bases de la conception... Faire du développement sans comprendre les diagrammes de classes ou les diagrammes de séquence (je parle bien de comprendre et pas de réaliser) n'est, à mon avis, pas possible...

[CinePhil]

Hélas, si, c'est possible !
Et ça donne des applications développées n'importe comment qui fonctionnent correctement au début et qui ne supporte pas la montée en charge. Vient alors le moment où on appelle un spécialiste pour dépatouiller le problème et qui s'arrache les cheveux rien que pour comprendre comment ça peut fonctionner.