J'aimerais savoir si avec la conception de programme via la méthode UML va entrainer la disparition de gestionnaire de base de données genre Oracle?

1- UML n'est pas une méthode
2- où tu compte stocker tes données si c'est pas dans une base ?
3- la réponse est donc non.

oui, à condition que des bases de données objet performantes voyent le jour (ce qui pour le moment est loin d'etre le cas).
En tout cas ce serait le mega pied : exit sql

wpk a écrit a écrit :   En tout cas ce serait le mega pied : exit sql

 
Depuis que j'ai gouté à OQL, j'ai décidé de supporter SQL

C'est pas un méthode de conception?
le "M" ne signifie pas "Method"?

 
Non.
 
Universal Modeling Language = Langage de Modélisation Unifié

kadreg a écrit a écrit :     Depuis que j'ai gouté à OQL, j'ai décidé de supporter SQL

 
ouais mais OQL c'est chiant justement parce que c'est completement batard, une vraie bdd objet n'a pas à se comporter comme une bdr. En occurence, t'as pas a mettre à plat un modele objet.............. c'est tout un programme qui est pour le moment loin d'etre une realité, malheureusement.

[edtdd]--Message édité par wpk--[/edtdd]

wpk a écrit a écrit :   ouais mais OQL c'est chiant justement parce que c'est completement batard, une vraie bdd objet n'a pas à se comporter comme une bdr. En occurence, t'as pas a mettre à plat un modele objet.............. c'est tout un programme qui est pour le moment loin d'etre une realité, malheureusement.

 
Pour moi, on s'en approche, mais d'une manière détourné. A savoir qu'a partir d'un modèle UML, de puis en plus, on est capable de générer automatiquement des tables (donc SGDBR) pour ranger un objet, et des méthodes pour le recharger/sauvegarder quand il faut (dans les accesseurs généralement).
 
Aujourd'hui les EJB fonctionnent sur ce type de principe. Avec la norme EJB 1.1, on le faisait 10 minutes parcequ'il y avait trop de problèmes (perfs à la con, gestion catastrophiques des relations entre objets). La norme EJB2 a amélioré les choses, donc ça en prend le chemin.

 
Tu dis ca a un analyste et tu te prends un coup de pied au cul toi :-p
 
Et c'est drole le débat, UML -> Fin des DBs... C'est comme les gars qui, meme si ils ont jamais fait un site sans frontpage vous disent XML ca va tuer l'HTML    
 
C'est très très très drole

Tu dis ca a un analyste et tu te prends un coup de pied au cul toi :-p
J'ai failli faire un arret cardiaque
 
Et c'est drole le débat, UML -> Fin des DBs... C'est comme les gars qui, meme si ils ont jamais fait un site sans frontpage vous disent XML ca va tuer l'HTML  
 
C'est une voie de recherche dans UML. Ce que ça va donner ? Des trucs appliqués dans des cas spéciaux. Pas de disparition des SGBD, au contraire, mais des configurations remontées au niveau UML (ah, mes tagged values {persistent} et {transient}).
 
C'est vraiment à l'usage que l'on va savoir ce que l'on y gagne

[edtdd]--Message édité par kadreg--[/edtdd]

buitoni a écrit a écrit :     Tu dis ca a un analyste et tu te prends un coup de pied au cul toi :-p   Et c'est drole le débat, UML -> Fin des DBs... C'est comme les gars qui, meme si ils ont jamais fait un site sans frontpage vous disent XML ca va tuer l'HTML     C'est très très très drole

 
bof, on vivra puis on verra
ce qui est sur c'est que les bdr, c'est tout sauf elegant et ergonomique qd on les utilise avec des langages objet. Une fois le constat fait, on peut tres bien chercher des solutions et ces solutions peuvent tres bien remplacer les anciennes methodes. C'est ce que s'appelle etre ouvert d'esprit et pas borné aux seuls sujets qu'on maitrise à peu pres...  
 
Kadreg> parfaitement d'accord sur les EJB le seul point noir à mon gout c'est que sun s'obstine a utiliser des SGDBR pour la persistence.