Différence entre l'analyse et la conception

bonjour,
avant de passer à l’écriture du code, il faut faire l'analyse et par la suite la conception
durant la phase de l'analyse, on utilise des diagrammes comme le diag de cas d'utilisation, le diag de classe le diag de séquence.
ces diag utilisés durant l'analyse, peuvent aussi étre utilisé durant la phase de conception
qu'elle est la différence entre ces diag utilisé durant la phase de l'analyses et ces même diag utilisée durant la phase de conception ?
est ce qu'on va ajouter ou supprimer des détails ? si oui , quelle sont alors ces détails ?
merci

Tu t'embêtes vraiment pour rien.

Commence par un bon vieux MCD (Modèle Conceptuel de Données) avec la méthode Merise et Merise 2 si tu as besoin de complexifier. Ensuite, si tu dispose d'un AGL, tu peux passer sur le MLD (Modèle Logique de Données) qui lui est compréhensible par un SGBD. Sinon, si tu n'as pas d'AGL, il faut relire toutes tes associations (CIF, Porteuses, etc) et en fonction des cardinalités, tu fais ce que tu as à faire.

Une fois que ton MLD est réalisé, tu peux créer ton script SQL en étant sur de faire le minimum d'erreur. Par contre, je te conseille pour chaque future table, d'avoir un jeu de donnée test afin de vérifier que tes informations soit pertinentes dans ta base et non redondante.

Après ça, tu as fini, félicitation.

L'UML (diagramme de classe) est un peu optionnel si tu fais ca -> si tu sais lire ton MLD, tu peux créer tes classes et tes traitements sans vraiment de problèmes puisque tout est implémenté dans ton schéma.

(La différence entre le MCD et le MLD se situe dans la modélisation des futures tables. Par exemple, une cardinalité 1,1 sur une table signifie qu'elle contiendra une clef étrangère de la table à laquelle elle est reliée par l'association. Dis comme ca, ca fait barbare, mais c'est pas si compliqué, promis !)

UndeadangerousK, la question de "je viens du sud" (original ! :) ) va au delà de la seule conception de la BDD.

L'analyse consiste à répertorier et préciser le besoin.
Le diagramme de cas d'utilisation est effectivement utile pour montrer au "client" (celui qui a le besoin du développement informatique) ce qu'on a compris de son besoin, d'une manière schématique et qu'il peut comprendre, avec des bonhommes en guise d'acteurs du système et des patates en guise de fonctions principales du système à développer. Le diagramme de cas d'utilisation aussi puisqu'il représente sur une échelle de temps l'enchaînement des opérations mais on le réservera pour les opérations "complexes". Je réserverais le diagramme de classe plutôt pour la phase de conception et uniquement pour la partie métier, pas pour la modélisation des données en vue de la création de la base de données. Je préfère largement le MCD de Merise pour ça et c'est un diagramme qui n'est pas forcément compréhensible par tout les types de clients parce que ça a quand même un côté très informatique.

L'analyse s'attachera également à prendre en compte l'existant et de faire préciser par le client ce qui doit être conservé ou ce qui doit être transformé en processus informatisés. On peut aussi préciser le degré de priorité et d'exigence (obligatoire, souhaité, optionnel, évolution future à prendre en compte durant la conception...) et les interfaces éventuelles avec d'autres systèmes, même des systèmes manuels (le logiciel doit éditer tel état qui sera utilisé par tel autre service, ce dernier n'étant pas destiné à être utilisateur du système informatisé à développer).

Durant la conception, on traduit ces besoins pour préparer le développement.

On commencera de préférence par la modélisation des données. Il peut être nécessaire, lors de la modélisation, de faire préciser des relations entre certaines données, des valeurs possibles (mini et maxi, liste de valeurs fixées, besoin d'une liste de données provenant de l'extérieur et régulièrement mises à jour...).

On proposera aussi assez vite des maquettes des principaux écrans du logiciel et qu'on fera valider par le client.
C'est aussi durant la conception que se fera le choix de la solution technique (SGBD, langage de développement, outil du commerce pré-formaté tel qu'un CMS, un CRM..., achat d'un serveur ou hébergement interne ou externe...).

Et quand on a des bases de conception suffisamment solides et acceptées par le client, on peut s'attaquer au dur du développement de la BDD et du logiciel.

Tout ceci n'est pas forcément linéaire. On peut commencer à développer alors que la conception n'est pas terminée mais il faut essayer de ne développer que ce qui a de bonnes chances de ne plus subir de modifications par la suite de la conception.