Discussion :

[maahlo]

Bonjour à tous,

je débute sur un Projet de developpement d'une application web du type:

- l' utilisateur se connecte depuis son browser, parcourt et recherche des publications enregistrées dans une BD.
- l'utilisatuer s'identifie/ s'enregistre pour pouvoir commander une publication.
- le paiement ne s'effectue que via une carte de crédit ou une visacard etc... (implique la sécurisation des accès).

Je m'occupe de la conception de l'application et j'aimerai savoir si:
1) il existe une méthode parente au OOSE et concue pour les applications de type web?
2) sinon puis-je me baser sur la méthode Unified Process par exemple pour la conception?
3) J'aimerai faire une ERM de la base de données. Dans quel contexte pourrai-je l'insérer dans la methode UP?
4) En ce qui concerne le choix du serveur d'application je suis perdu, comment discerner le plus adapté, d'où ma dernière question:
Pour ce genre d'application aurait-on besoin de la couche métier? De sorte que je penche pour les JSP/Servlet+EJB c'est à dire une solution J2EE+MySql
ou alors Apache Server +PhP +MySql ferait bien l'affaire?
L'une des conditions majeures est de proposer une architecture de moindres coûts.
Quelqu'un aurait-il un exemple de conception ou bien plan de projet de ce type à me proposer?
Je m'excuse de la longueur de ce post et espère ne m'être pas trompé de forum.
Merci d'avance pour votre aide, vos réponses ou suggestions

[cinemania]

Personnellement je ne vois pas ton problème... mais bon...

En fait, le vrai problème c'est le choix de la technologie pour implanter le site.
Que tu fasse du PHP ou des JSP au fond ca ne change rien.

La personne se connecte, s'authentifie, accède à des informations, et fait un achat. Dans tous les cas tu utilise des objets métier.
Dans ton cas à première vue, on peut faire une première estimation sans analyse, à la louche de User//Client, Publication, Payment. Le dernier va dépendre de tas de paramètres mais est cencé représenter un payement qui sera normallement stocké dans la base, pour être traité plus tard, coté entreprise, à moins que tu ne passe par un "provider" qui se débrouille et te retourne juste un résultat indiquant que le payement est bien fait avec les informations sur la transaction.
Nombre de sites actuellement n'utilisent pas leur propre système de payement en ligne, mais ceux mis en place par leur banque, ou leur fournisseur d'accès à internet, ou encore d'autres prestataires "dédiés" au payement en ligne.
Ton modèle va varier selon que tu gère toi meme le payement en ligne, ou que tu passe par un organisme tiers... ce sont donc des choses qu'il faut prendre en compte au moment de la conception...

En effet, si tu décide de faire un site comme la fnac, tu conserve une fiche client et dans cette fiche client tu conserve une trace de la carte bancaire pour éviter que le code ne transite à nouveau sur le net (meme avec les SSL... la sécurité absolue n'existe pas)
Dans ce cas tu aura les objets métiers suivant (a priori)
Client, CB, Facture, Commande
Commande etant les commandes en cours et l'historique, avec la date, l'adresse de livraison et de facturation, si différente des informations du client.
Client ba le client avec son identification, son adresse ... et un lien vers une ou plusieurs cb.
Dans CB tu as les traces de CB que tu conserve.

Ensuite c'est le service comptable en accèdant a une interface spécifique qui voit les commandes et le moyen de payement associé et fait le prélevement en temps voulu.
Cette solution bien que super user-friendly pose d'énormes problèmes de sécurité en ce qui concerne la CB... il est donc nécessaire d'avoir une vraie base de données type Oracle, SQL Server, Informix, DB2 (et oui yen a encore) ou je ne sais quoi d'autre et d'utiliser autre chose que PHP. ASP.NET ou JSP par exemple.
Car même si ta page utilise SSL... il n'en reste pas moins que les environnements comme PHP sont souvent attaqués.

Le Modele de ta base de donnée suivra le schéma métier... sans plus.
Attention toutefois quand tu fait ton analyse à tenir compte de l'éventuelle montée en charge de ta base de données, cela peut influer sur ta façon de modéliser les relations et les divers objets.

[maahlo]

en fait, concernant les 3 premières questions il s'agissait de choisir une methode de developement qui aborde le sujet de facon pédagogique. J'ai opté pour le RUP et vu mon cas je me limiterai aux phases conception et Design (bien-sur OO).

Vu le problème de sécurité que peut causer la CB je vais pencher pour les services d'un organisme de paiement et si necessaire ceux de la banque.
car voulais pas sortir du cadre de l'open source, et ça me tracasse de devoir utiliser une DB autre que MySql.
Qu' entends-tu exactement par "Le Modele de ta base de donnée suivra le schéma métier..."?



merci de ton aide