Application de facturation automobile
Greo
Membre
Bonjour,
Je me mets sérieusement à Cocoa et je me suis lancé un projet personnel. Je suis actuellement en 3ème année d'école d'Ingénieur Réseaux et Systèmes d'Information. Je connais le langage C, JAVA, Ruby et PHP.
Mon projet consiste à réaliser une application Cocoa de facturation automobile. Il y aurait des clients, des véhicules, des articles avec stock et des factures, je prévois ultérieurement d'ajouter une partie comptabilité avec les stocks vendus.
J'ai lu plusieurs fois ce bouquin Programmation Cocoa sous Mac OS X. Et j'ai du mal à savoir par où commencer. Je vois à peu près quels APIs je vais utiliser : Core DATA, NSTabView...
Si j'ai bien compris MVC, j'aurais les modèles suivants :
Que me conseillez-vous pour commencer ? UML, Meurise, cahier des charges... Je suis un peu perdu.
Merci.
Je me mets sérieusement à Cocoa et je me suis lancé un projet personnel. Je suis actuellement en 3ème année d'école d'Ingénieur Réseaux et Systèmes d'Information. Je connais le langage C, JAVA, Ruby et PHP.
Mon projet consiste à réaliser une application Cocoa de facturation automobile. Il y aurait des clients, des véhicules, des articles avec stock et des factures, je prévois ultérieurement d'ajouter une partie comptabilité avec les stocks vendus.
J'ai lu plusieurs fois ce bouquin Programmation Cocoa sous Mac OS X. Et j'ai du mal à savoir par où commencer. Je vois à peu près quels APIs je vais utiliser : Core DATA, NSTabView...
Si j'ai bien compris MVC, j'aurais les modèles suivants :
- Client
- Véhicule
- Article
- Facture
Que me conseillez-vous pour commencer ? UML, Meurise, cahier des charges... Je suis un peu perdu.
Merci.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Puis UML je pense. Je ne connais pas meurise (juste le meurisier :P ).
Le code viendra après, et oui tu auras besoin de CoreData pour les bases de données (ou SQLite), mais si l'application n'est que Mac, fonce sur CoreData.
Bon courage!
As tu regardé l'outil de modélisation qui va avec Core Data ?
Il me semble que tu ne devrais pas avoir besoin de beaucoup plus ..
L'inconvénient majeur, à mes yeux, de Core Data c'est qu'il faut bien avoir défini son modèle au départ sinon si on le change en cours de route alors qu'on a déjà des données il faut utiliser un outil de migration. Sauf si on ne fait qu'ajouter des propriétés ou des relations.
Par contre, si le modèle est déjà bien constitué sur le papier, il est assez facile à construire dans Xcode car on peut tout voir du "Graphe" des objets.
C'est dommage qu'on ait pas le même outil pour les classes, ne serait ce que de visualisation (ce qui existe n'est pas aussi pratique on voit trop de choses à mon avis).
MVC est lié à des conceptions logicielles. UML permet de conceptualiser le modèle de ton projet
Les deux ne sont pas forcément incompatibles, ce sont juste deux façons et approches différentes.
MCD = Approche base de données, tu te concentre sur comment vont être organisées tes données dans ta base.
Le MCD peut aider à la partie M du MVC, à savoir comment tu vas organiser ton modèle.
L'UML peut t'aider à faire de même.
Mais si tu conceptualises ton modèle utilisé via MVC à l'aide de ton MCD, ton modèle logiciel va être fortement lié à ta base de données. Si un jour tu changes la structure de ta base, par exemple pour des raisons d'optimisation de ta base, ou parce que tu passes d'une base sqlite3 locale à une base Oracle serveur, et que cela t'oblige (pour des raisons de contraintes entre les tables, ou autre) à modifier ton MCD... ton modèle du MVC qui était fortement lié à ton MCD va être impacté.
Si tu penses à ton MVC indépendemment du modèle de données (MCD), tu peux décoreller les deux.
Autre exemple, dans ton MCD tu feras transparaà®tre les tables intermédiaires te permettant de faire les relations many-to-many. Par exemple si tu as des utilisateurs et des voitures, et qu'un utilisateur peut avoir plusieurs voitures, et une voiture plusieurs utilisateurs... dans ton MCD tu devras avoir une table qui listera toutes les relations user/car. Sur ton UML (qui va te servir à faire ton modèle de MVC) pas besoin de faire apparaà®tre ça.
Au final, les deux approches servent certes à faire des modèles, mais ton modèle pour la manipulation de tes données dans ton soft, par ton contrôlleur (donc celui du MVC, fait par UML) pourra être différent de ton modèle de stockage (MCD). Certes souvent ils se ressemblent fortement, et souvent c'est bien pratique que les deux collent pour que la couche d'interface entre le stockage (en BDD) et le modèle manipulé (MVC) soit minimaliste, même si cela implique une forte adhérence entre les deux.
J'ai réalisé le MCD.
Bon pour ceux qui ne connaissent pas cet outils, le MCD (Modèle conceptuel de données) représente comment sont organisées les données.
Les rectangles identifient une entité qui sera plus tard une table et les cercles représentent une association qui selon le cas peut devenir une table. Tout dépend des cardinalités.
Le sens de lecture des cardinalités et le suivant. Exemple, si on prend les entités suivantes : Address_customer, City et l'association Address_customer_city, on dira que une adresse client peut être associée à une et une seule ville et inversement, une ville peut être associé à 0 ou N adresse client.
On ne peut jamais avoir de cardinalités qui commencent par un 1 des 2 côtés car cela génère une contrainte. C'est à dire qu'un élément doit avoir un autre élément pour être créé et que cet autre élément doit également avoir le premier élément, donc c'est le chat qui se mord la queue.
Dans le cas où on a une cardinalité N N comme address_customer_city cela signifie qu'il y aura une table intermédiaire. Dans ce cas, cela signifie qu'une ville pourra être associée à plusieurs adresses clients et qu'un client pourra être associé à plusieurs adresses clients. Afin de pouvoir gérer et garder un historique des déménagements du client.
Voilà ...
Par contre la différence, c'est qu'en UML, tu fais apparaà®tre des héritages, et tu peux si ça t'arrange avoir une cardinalité 1-1.
Pour la cardinalité, par exemple, tu peux avoir une classe "Couleur", qui a les attributs "Rouge", "Vert" et "Bleu". Et tu peux après avoir une classe Voiture qui a un attribut couleur_carrosserie de type Couleur, et une classe Utilisateur qui a un attribut couleur_cheveux de type Couleur aussi. Au lieu d'avoir un attribut couleur_carroserie_rouge, couleur_carroserie_vert et couleur_carrosserie_bleu du coup l'attribut est lié à un autre objet, de type Couleur, ayant lui-même des attributs.
Pour l'héritage, tu peux avoir une classe Vehicule, et deux classes filles "Voiture" et "Camion" par exemple. Ce que tu peux faire apparaà®tre dans ton UML, tous les attributs communs à tous les Vehicules (plaque_immatriculation, ...) étant dans la classe mère. Chose que tu ne peux pas faire dans un MCD... (à part éventuellement avec une cardinalité 1-1 entre une table Voiture et une table Vehicule, et pareil pour Camion-Vehicule justement)
Peut on partir du principe que chaque entité est une classe modèle ?
Quelle est la prochaine étape ?
Concernant les cardinalités, j'ai l'impression que ça ressemble à l'entité ville c'est à dire qu'elle réutilisé par les clients et les fournisseurs.Ï€