Discussion :

[souviron34]

J'ai l'exemple assez récent d'un client dont les données étaient très mal formalisées : après discussion, on s'est rendu compte que même eux ne comprenaient pas ce qu'ils manipulaient.

comme le dit chaplin

Mais c'est bien toute la force des études ergonomiques amont, ainsi que des études et tests d'utilisabilité...

Il est absolument normal que le schéma de pensée des informaticiens ne suivent pas celui des utilisateurs...

Et que les utilisateurs n'envisagent pas leur métier sous la forme de "données" et de "processus"...

C'est justement là qu'interviennent les "bonnes" personnes, structures d'équipes et de projets, dont on a déjà discuté dans le thread "les bonnes pratiques"...

[_skip]

Les bonnes pratiques pour bien pratiquer...
Si seulement ça existait pour de vrai, on sait tous qu'il faut des analyses rigoureuses des besoins utilisateurs... Analyses que personne veut payer, de toutes façons quoi qu'on fasse c'est trop cher et insuffisant parce que les gens comprennent pas qu'un logiciel c'est pas pilote automatique qui fait le boulot pendant qu'on joue au golf.

Actuellement les clients de la société ou je bosse sont tous des compagnies IT et franchement ça fait un bien fou de discuter avec des gens qui parlent la même langue que nous.

Bon, ma minute trollesque écoulée , je voudrai reprendre un point :

De mon point de vue (et ce qui m'est, avec l'expérience, apparu comme le plus souple, maintenable, et indépendant) est de considérer une base (et un serveur), comme un fournisseur de données élémentaires. Tout formattage / restructuration doit être fait côté appli (client).

A mon avis, et c'est là un écueuil rencontré très souvent (il suffit de lire les posts de ce thread), tu tombes justement dans le "piège" technique..

Oui mais pour que l'application soit utilisable et que les temps nécessaires à la restitution des données soient acceptables, il faudra de toutes façons s'inquiéter de la façon dont elles sont stockées et donc vraisemblablement du schéma de données.

Des choses se font facilement en objet lorsque tout est joli en mémoire, mais comment ça donne lorsqu'il faut modéliser son super domain model bourré d'héritage et d'autojointures en relationnel, tout en étant capable d'en recracher des collections à la vitesse de l'éclair?

[souviron34]

Des choses se font facilement en objet lorsque tout est joli en mémoire, mais comment ça donne lorsqu'il faut modéliser son super domain model bourré d'héritage et d'autojointures en relationnel, tout en étant capable d'en recracher des collections à la vitesse de l'éclair?

Vraisemblablement parce que les paradigmes ou modèles associés à la Base d'un côté, aux applis de l'autre, ne devraient pas être les mêmes ou ne sont pas les bons...

Et que peut-être que (par exemple) l'OO n'est peut-être pas la bonne approche dans ce cas-ci .. ?

[GrandFather]

Et que peut-être que (par exemple) l'OO n'est peut-être pas la bonne approche dans ce cas-ci .. ?

Celle-là je l'attendais

Il n'est pas question dans ce fil de savoir si l'OO est pertinent ou pas pour un problème donné, mais de se prononcer sur les frameworks objet réduisant les BDD à un rôle subsidiaire de persistance (subsidiaire en terme d'effort de conception), comparativement à d'autres approches exploitant au maximum les possibilités de la base de données, le modèle objet utilisé par l'application cliente lui étant alors subordonné.

Il est évident que si tu n'utilises pas la POO, la question n'a plus aucun sens. Le cas évoqué par _skip est celui d'une modélisation poussée à son paroxysme sans prendre en compte les contraintes et les limitations d'une partie de la plateforme technique (en l'occurrence l'ORM utilisé et/ou la BDD).

[benwit]

Celle-là je l'attendais

Moi aussi !

Souviron, le sujet "anti" objet !

[souviron34]

Celle-là je l'attendais

Moi aussi !

Souviron, le sujet "anti" objet !

Mais je répondais strictement au post cité


PS : je ne suis pas "anti", j'attends juste la preuve que c'est mieux que le reste, et je ne la vois pas..

[_skip]

Et que peut-être que (par exemple) l'OO n'est peut-être pas la bonne approche dans ce cas-ci .. ?

Mais j'apprécie cette réponse .

[_skip]

mais de se prononcer sur les frameworks objet réduisant les BDD à un rôle subsidiaire de persistance (subsidiaire en terme d'effort de conception), comparativement à d'autres approches exploitant au maximum les possibilités de la base de données, le modèle objet utilisé par l'application cliente lui étant alors subordonné.

Oui, sans parler de base de données épaisses (qu'on se comprenne tous).

Certains frameworks ORM proposent de commencer par une approche objet, c'est une chose, mais également de s'occuper de TOUT ce qui a trait à la base de données. Ce qui inclus les DDL, la création des tables, en bref la gestion complète du schéma.

[pseudocode]

Et que peut-être que (par exemple) l'OO n'est peut-être pas la bonne approche dans ce cas-ci .. ?

+1

L'OO (enfin l'OOP pour être exact) est un paradigme de programmation. On peut le dénaturer pour en faire un modèle de définition de donnée (en supprimant l'aspect méthode/message, aka Plain-Old-*-Object), mais ca n'en reste pas moins une "magouille". Tout comme mettre des procédures stockées dans une BDDR n'est pas très "naturel" a mon sens.

Lorsqu'on parle de modélisation du domaine métier, on fait référence à deux aspects : le modèle de données (data model) et le modèle de processus (process model).

Comme l'a dit _skip, penser son modèle "métier" en se concentrant uniquement sur l'aspect "data model" (donc statique) des choses peut conduire à des gros problèmes de perfs/fonctions :
- comment construire rapidement des "vues" dans un programme OO ?
- comment construire des processus complexes dans une BDDR ?

Raison de plus pour moi de penser que les modèles OO/Relationnels sont déjà une solution technique et qu'il faut un modèle plus agnostique en amont.

[benwit]

L'OO (enfin l'OOP pour être exact) est un paradigme de programmation. On peut le dénaturer pour en faire un modèle de définition de donnée (en supprimant l'aspect méthode/message, aka Plain-Old-*-Object), mais ca n'en reste pas moins une "magouille". Tout comme mettre des procédures stockées dans une BDDR n'est pas très "naturel" a mon sens.

Entièrement d'accord avec ça

Lorsqu'on parle de modélisation du domaine métier, on fait référence à deux aspects : le modèle de données (data model) et le modèle de processus (process model).

Egalement rencontré très souvent (trop souvent ?)
A la réflexion, est-ce "normal" de scinder ces deux aspects ? Est-ce par habitude ? Parce qu'on n'a pas trouvé mieux pour modéliser ?

[davcha]

PS : je ne suis pas "anti", j'attends juste la preuve que c'est mieux que le reste, et je ne la vois pas..

Quel est le meilleur paradigme selon toi ? objet, impératif, fonctionnel, prog par contraintes... ?

[GrandFather]

PS : je ne suis pas "anti", j'attends juste la preuve que c'est mieux que le reste, et je ne la vois pas..

La preuve que c'est mieux, tu vas l'attendre encore longtemps... Depuis trente ans environ que le concept existe et a été éprouvé dans des projets logiciels de toutes tailles, qu'il a fait l'objet d'innombrables études académiques et de milliers d'ouvrages, on commence à avoir une « petite » idée des forces et des faiblesses du paradigme. Cela fait déjà longtemps qu'est parvenue la conclusion que ce n'est pas une panacée universelle et qu'il n'est pas optimal pour absolument tous les cas de figure, mais qu'hormis ces cas assez particuliers il y avait tout intérêt à l'adopter. Remettre en cause cette conclusion pourtant pas toute neuve, c'est se complaire dans le combat d'arrière-garde.

Cela dit, je le répète, on parle ici d'un choix méthodologique à opérer dans un contexte objet. Donc la réponse du style « ben t'as qu'à pas utiliser d'objet et le problème est réglé » relève au mieux de la boutade, au pire du troll. J'ose espèrer que la première hypothèse est la bonne ?

[GrandFather]

Raison de plus pour moi de penser que les modèles OO/Relationnels sont déjà une solution technique et qu'il faut un modèle plus agnostique en amont.

C'est sûr que c'est un peu l'union de la carpe et du lapin... Mais est-ce qu'il existe un tel modèle, et aurait-il un véritable intérêt pratique ?

[mon_nom_est_personne]

Quel est le meilleur paradigme selon toi ? objet, impératif, fonctionnel, prog par contraintes... ?

Je trouve que le cote objectivement "meilleur" de la question est un peu reducteur. Tout depend de l'algo de l'utilisation. Par exemple rien mieux que du fonctionnel pour les algo super recurcive (epargnez-moi svp la remarques des appelles de methode recurcif) genre programmation genetique ou tout ce qui est relatif au arbre . L'objet c'est tres dans le design de systeme. Encore une fois, la grosse erreur c'est de faire rentrer un projet dans une techno ou un paradigme au lieu de l'inverse.

[pseudocode]

C'est sûr que c'est un peu l'union de la carpe et du lapin... Mais est-ce qu'il existe un tel modèle, et aurait-il un véritable intérêt pratique ?

Bah, des modèles y en a plein : depuis la discussion sur dictaphone avec les experts jusqu'aux modélisations formelles. Ce que je rencontre le plus fréquemment c'est la représentation "patatoide" avec flèches et annotations.

Mais bon, je préfère encore ça a une représentation 100% E/R ou UML dans un CDCF. Quand je vois ce genre de représentation, je me demande toujours quels compromis (magouilles ?) ont été faits pour que le "vrai" modèle métier rentre dans le schéma.

Quand à savoir s'il y a un intérêt pratique, on ne peut le savoir qu'après coup. Mais on peut se poser la question : est-ce que des entreprises comme Google utilisent E/R ou UML pour représenter leur data-model ?

[GrandFather]

Bah, des modèles y en a plein : depuis la discussion sur dictaphone avec les experts jusqu'aux modélisations formelles. Ce que je rencontre le plus fréquemment c'est la représentation "patatoide" avec flèches et annotations.

OK pour modéliser le métier et s'assurer avec les experts métier que rien n'a été oublié et qu'il n'y a pas de contresens, mais quid pour modéliser le système informatique qui va l'implémenter ? Comment passer d'un système de représentation à l'autre sans rien perdre (les AGL avec reconnaissance vocale sont encore assez rares ) ?

Quand à savoir s'il y a un intérêt pratique, on ne peut le savoir qu'après coup. Mais on peut se poser la question : est-ce que des entreprises comme Google utilisent E/R ou UML pour représenter leur data-model ?

Vu le secret impénétrable avec lequel Google entoure tous ses procédés, la question est purement rhétorique.

[pseudocode]

OK pour modéliser le métier et s'assurer avec les experts métier que rien n'a été oublié et qu'il n'y a pas de contresens, mais quid pour modéliser le système informatique qui va l'implémenter ? Comment passer d'un système de représentation à l'autre sans rien perdre (les AGL avec reconnaissance vocale sont encore assez rares ) ?

heu... utiliser le cerveau de l'architecte ! Désolé mais je ne connais pas de méthode formelle pour faire ce genre de chose.

Ce que je fais généralement, c'est séparer ce qui est purement "data model" (les entités/attributs/relations qui sont invariantes dans le temps) et ce qui est purement "process model" (les opérations/traitements à effectuer sur le data model).

Ensuite, il reste la zone grise : les amalgames "data+process" qui existent à un moment du traitement mais qui ne font pas partie du modèle métier (= "vues") ou pas persistantes à long terme (= "états temporaires").

Ce sont les contraintes de cette zone grise qui m'orientent dans des choix techniques (vue dynamique ou pré-calculée, sérialisation binaire ou représentation DDL, stockage "raw" en base ou indexation de fichier, ...).

Bref, pas de solution miracle. Juste essayer de quantifier un minimum les objectifs/risques fonctionnels et de s'occuper du plus important/risqué d'abord.

[souviron34]

Quel est le meilleur paradigme selon toi ? objet, impératif, fonctionnel, prog par contraintes... ?

Depuis trente ans environ que le concept existe et a été éprouvé dans des projets logiciels de toutes tailles, qu'il a fait l'objet d'innombrables études académiques et de milliers d'ouvrages, on commence à avoir une « petite » idée des forces et des faiblesses du paradigme. .... mais qu'hormis ces cas assez particuliers il y avait tout intérêt à l'adopter. Remettre en cause cette conclusion pourtant pas toute neuve, c'est se complaire dans le combat d'arrière-garde.

mais quid pour modéliser le système informatique qui va l'implémenter ?

Comme dans tous les aspects de la vie courante, en informatique je suis pareil : contre la bien-pensance et le politiquement correct...

Or je ne vois pas de cas de "hormis ces cas assez particuliers il y avait tout intérêt", mais plutôt des esprits formés et formattés par des formations...

Et ce n'est pas de l'arrière-garde, c'est de l'ouverture d'esprit et de la liberté...

Si vous vous sentez bien dans un modèle, tant mieux pour vous..

Mais la Pensée Unique me débecte...


Et ce n'est pas la "réussite" (voir les échecs cuisants, et ne serait-ce que le thread sur "les raisons des échecs") de certains projets qui me feront changer d'avis : je ne crois pas qu'il y ait plus intérêt à adopter une approche plutôt qu'une autre, et je m'insurge contre cela..


Que vous y soyez plus à l'aise car on vous l'a enseigné, et vous avez l'esprit plutôt orienté comme ça, soit..

Mais je ne crois pas que cela amène une meilleure représentation ou réalisation dans l'absolu....


Le fait de dire "Remettre en cause cette conclusion pourtant pas toute neuve, c'est se complaire dans le combat d'arrière-garde" me semble du même acabit que de dire que "le réchauffement climatique est d'origine humaine, c'est prouvé, et tous ceux qui disent le contraire sont des suppôts du Grand Capital"...



PS : d'ailleurs, pourquoi vouloir modéliser un système informatique ???? modéliser des structures de données, soit... Architecturer un système, soit.. Modéliser un système ??

Je trouve que le cote objectivement "meilleur" de la question est un peu reducteur.
... Encore une fois, la grosse erreur c'est de faire rentrer un projet dans une techno ou un paradigme au lieu de l'inverse.

+10000

Bah, des modèles y en a plein : depuis la discussion sur dictaphone avec les experts jusqu'aux modélisations formelles. Ce que je rencontre le plus fréquemment c'est la représentation "patatoide" avec flèches et annotations.

heu... utiliser le cerveau de l'architecte ! Désolé mais je ne connais pas de méthode formelle pour faire ce genre de chose.
....
Ce sont les contraintes de cette zone grise qui m'orientent dans des choix techniques (vue dynamique ou pré-calculée, sérialisation binaire ou représentation DDL, stockage "raw" en base ou indexation de fichier, ...).

Bref, pas de solution miracle. Juste essayer de quantifier un minimum les objectifs/risques fonctionnels et de s'occuper du plus important/risqué d'abord.

+10000

Cela dit, je le répète, on parle ici d'un choix méthodologique à opérer dans un contexte objet. Donc la réponse du style « ben t'as qu'à pas utiliser d'objet et le problème est réglé » relève au mieux de la boutade, au pire du troll. J'ose espèrer que la première hypothèse est la bonne ?

Non, voir ci-dessus..

Mais j'arrête là ma participation... Ne pouvant donner qu'un point de vue de logique et non d'argumentaire technique...

[GrandFather]

@souviron: Je ne commenterai même pas ce délire sur la « pensée unique » et me contenterai de répondre à ce qui n'a qu'un rapport, même lointain, avec la discussion :

PS : d'ailleurs, pourquoi vouloir modéliser un système informatique ???? modéliser des structures de données, soit... Architecturer un système, soit.. Modéliser un système ??

Je travaille dans une entreprise comportant une dizaine de centres informatiques régionaux, une centaine de centres départementaux, des centaines d'applications métiers front-end, des process de production complètement automatisés, et des interactions complexes avec des entreprises tierces. Comment fait-on pour comprendre et appréhender sous une forme synthétique ne serait-ce qu'une fraction d'un tel ensemble sans employer une quelconque forme de modélisation ? En relisant toutes les lignes de code et en épluchant les bons de livraison fournisseur ?

P.S. (tout de même) : puisque le « vous » de « Que vous y soyez plus à l'aise car on vous l'a enseigné, et vous avez l'esprit plutôt orienté comme ça, soit.. » m'inclut vraisemblablement, je peux au moins répondre en mon nom propre. Etant totalement autodidacte, je ne peux même pas incriminer l'enseignement pour expliquer mon « formatage » et ma soumission à la « pensée unique ». C'est de la pure auto-suggestion.

[B.AF]

Je crois surtout que ce qui est important, c'est que la théorie de façon excessive est nuisible car elle écarte de la réalité.
C'est un peu là qu'est l'ambiguité de la bonne approche : elle peut être bonne dans son contexte, et très mauvaise d'un point de vue académique.

La trop grosse croyance dans la théorie peut amener à des catastrophes sans nom, de même que l'ignorance des fondamentaux.

Comme dirait l'autre il y a 3 méthodes : la bonne, la mauvaise, et la mienne.

Pour réussir un projet que qu'il soit, il faut
1 dose d'organisation
1 dose de technicité
1 dose d'implication
1 dose de sens client
1 trait de génie
1 équipe homogéne
1 techno saine et connue de l'équipe

Ben mine de rien, cette recette à l'air si anodin, c'est le souflé au fromage : tout le monde en parle, tout le monde connait la recette, pourtant, tous les jours, tout le monde le rate.