Discussion :

[Nico64]

Bonjour,

J'ai du mal à comprendre comment passer de la phase d'analyse à la phase d'architecture logicielle, notamment pour identifier les solutions possibles les plus pertinentes (SGBDRO ou pas, type de client, type de protocole d'échange de données, format des données ...) .

Connaissez-vous des références (web, bouquins ...) qui détaillent cette démarche, et qui présentent les meilleures solutions à mettre en oeuvre selon le besoin ?

Merci !

[cinemania]

au risque de paraitre condescendant,

connais tu UML ?

Non treve de plaisanterie, il n'y pas de vraie solution miracle pour choisir telle ou telle modele d'architecture...

C'est selon le besoin que telle ou telle architecture peut s'avérer la meilleur, mais pour cela, cela suppose que tu connaisse deja relativement bien les différentes architectures "générales" qui s'offre à toi, pour le cas en cours.

Je ne vais pas opter pour une architecture distribuée dans le développement d'un jeu en ligne genre mmorpg car meme s'il pourrait fonctionner, n'est pas le modele d'architecture général le plus pertinant.

[amazircool]

RUP c’est la meilleur solution pour diminuer le risque de développement et accélérer le temps :=)

[souviron34]

Bonjour,

J'ai du mal à comprendre comment passer de la phase d'analyse à la phase d'architecture logicielle, notamment pour identifier les solutions possibles les plus pertinentes (SGBDRO ou pas, type de client, type de protocole d'échange de données, format des données ...) .
!

Comme l'a dit cinémania, aucune REGLE.

Il faut tenir compte de ce qu'on souhaite, du budget, du marketing, des clients potentiels, de l'architecture "ergonomique" des fonctionalités, des matériels nécessaires/et/ou possibles, des systèmes sur lesquels cela doit tourner, du style de l'équipe (petite, grande, très grande), du style de maintenance souhaitée (in-house, extériorisée, etc..), des standards existants, des réglements éventuels (militaire, santé, etc..) existants, bref de tout un tas de paramètres...

En principe, au moment de l'analyse, les principaux choix sont faits.
Dans le cycle en V, l'architecture est la deuxième étape, tout de suite après la spécification système/logiciel... Et avant l'analyse...

Personellement, le seul choix que je déléguerais tout en bas de l'échelle serait justement celui de l'outil de BD. Car à mon avis on devrait pouvoir changer de BD, de moteur ou de structure de BD, sans changer l'application..

Mais ce n'est que mon avis avec mon expérience, et visiblement peu de projets actuels suivent cette tendance...

[cinemania]

Tout a fait d'accord avec souviron34,

Avec cependant un Bémol. En effet, quand on parle de base de données, il faut se mettre d'accord.

En effet, à ce jour il existe plusieurs familles de SGBD. Or tous ne sont pas utilisables pour des projets professionnels de "grande envergure".
Je suis donc d'accord sur le choix de reléguer le choix du SGBD en bas de l'échelle à condition de faire un choix de famille au commencement, et malheuresement de ce limiter à cette famille dans le choix final.

Sans entrer dans les détails... si on a une appli très simple genre web, sans besoin de sécurité accrue, ni de flux énormes, bref quelque chose de très simple, on peut opter pour des bases non relationnelles et non transactionnelles (MySQL), malheureusement dans la plupart des cas il faut une base de données au minimum transactionnelle et de préférence relationnelle.
Certes MySQL, par exemple, implante des modeles transactionnelles et relationnelles, mais pas pour tous les types de tables, et par défaut les tables sont non transactionnelle et non relationnelles... de plus il faut des modules à part compilés avec pour activer ces fonctionnalités... ce qui n'est pas l'idéal, en plus question sécurité on a vu mieux.

Pour rappel, si le projet peut se contenter d'une base non transactionnelle et non relationnelle, on peut totalement délégué le choix de base en fin de chaine car qui peut le plus peut le moins. Dans le cas contraire... il faudra faire attention au choix en fin de chaine ...

[souviron34]

mwé je maintiens cependant mon point de vue

je dirais que ce qui pêche beaucoup dans beaucoup d'applications et d'architectures, quels que soient les domaines d'applications, est justement le fait de s'orienter dès le début..

Ce que je prône et effectue dans mes applications, c'est avoir un module séparé en bout de chaîne (en bas) qui est censé "envoyer" ou "recevoir" des données. Si on fait une BD directe, on met la lecture/écriture directement dans le code à cet endroit-là. Si on fait appel à une BD, qu'elle soit relationnelle, objet, ou autre, on restreint les appels à ce module-là. En effet, dans ces cas-là, en général on attaque un serveur. Et dans ce cas, on formatte des requêtes et interprête des réponses. Mais cela ne devrait avoir aucune influence sur le reste du code.

L'architecture globale ne dépend donc pas de la BD, et les éléments nécessaires à la construction d'une requête, ou l'information susceptible d'être tirée d'une réponse, qui forcément devront être visible par l'utilisateur ou une partie de l'appli, sont passés en paramètres (structure ?) aux routines chargées d'"envoyer" ou "recevoir" les données. Ainsi le reste de l'application est totalement indépendant du dialogue s'instaurant dans ces routines.

Mais comme je dis, je sais que je suis assez isolé dans ma manière de penser

[cinemania]

La seule chose ke je dit c'est que finallement dans certains cas tu t'interdit certains types de SGBD.

Maintenant le choix du SGBD on s'en tappe.

Mon dernier gros projet peut fonctionner indépendemment sur n'importe quel type de base de données relationnelle, ensuite soit ya un pilote natif, soit faut ya accèder par odbc... suffit juste de lui dire quel pilote de base de données tu veux utiliser, et la chaine de connexion et voila

En fait pour palier a des problemes à la con, mon projet charge une assembly qui gere l'accès aux bases de données, c'est cette assembly chargée dynamiquement qui fait elle meme les appels et formatte les requetes,
surtout pour des besoins spécifiques comme l'obtention d'un profil de procédure stockée ...
Et oui... autre raison pour laquelle tu dois savoir dès le départ vers quelle famille de SGBD tu t'oriente, c'est par exemple, les procédures stockées si lieu il y a d'en utiliser.
Nombres de sgbd ne supporte pas les procédures stockées, et n'en déplaise à certains cela n'a rien avoir avec les requetes préparées.

Bon c'est vrai ta couche d'accès peut les émuler si yen a pas c'est vrai aussi, mais pourquoi réinventer la roue ...

[souviron34]

puisqu'on en est à parler à parler de projets moi j'en ai un où je gère (le même serveur a plusieurs serveurs esclaves, chacun attaquant des bd différentes (oracle, access, flat files, objets, etc..). mon appli dialogue avec ce "dispatcher", qui lui dispatche la requête vers le serveur approprié, qui lui et lui seul connait sa db...

[Hephaistos007]

Ce que tu cherches, ce sont des patterns d'architectures. IBM a fait l'effort de lister les solutions architecturales pour des besoins récurrents, organisés en catégories. Cependant, la somme d'information produite est énorme et honnêtement peu accessible au néophyte (mais super pour les consultants "haut de gamme"). Jettes un oeil là : http://www.opengroup.org/architectur...ch/chap28.html et suis les liens.