Réussir un projet d'UML
Fermé
mario002e
Messages postés
82
Date d'inscription
samedi 29 septembre 2007
Statut
Membre
Dernière intervention
8 mai 2012
-
Modifié par mario002e le 13/09/2010 à 12:47
emy - 25 avril 2013 à 12:02
emy - 25 avril 2013 à 12:02
A voir également:
- Réussir un projet d'UML
- Gantt projet - Télécharger - Gestion de projets
- Musique projet x - Forum Musique / Radio / Clip
- Musique du film Projet X - Forum Musique / Radio / Clip
- Partager un projet imovie modifiable - Forum MacOS
- Projet vba exemple ✓ - Forum VB / VBA
4 réponses
blackdragon5040
Messages postés
63
Date d'inscription
samedi 6 mars 2010
Statut
Membre
Dernière intervention
8 décembre 2011
11
13 sept. 2010 à 16:27
13 sept. 2010 à 16:27
Hello !
C'est bien de faire de la modélisation UML. C'est toujours mieux d'utiliser des standards reconnus.
Quelques liens pour apprendre :
- http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML.html
- http://www.agilemodeling.com/essays/umlDiagrams.htm
Tu peux aussi trouver de bons livres sur Amazon
Et un logiciel simple et gratuit pour faire des diagrammes :
- http://alexdp.free.fr/violetumleditor/page.php
Tu peux aussi utiliser argoUML si tu veux générer du code.
Voilà ce que je conseille :
- Faire une analyse des besoins et un cahier des charges
- Commencer par Use-Case pour montrer les acteurs et les fonctionnalités nécessaires
- Continuer avec des diagrammes Activity et Class pour découper le projet en classes et représenter la logique de l'application
- Continuer avec des diagrammes Sequence pour modéliser les actions en détail
- Implémenter et bien documenter son code, garder les diagrammes à jour par rapport au code
Voilà ! J'espère que ça aide.
C'est bien de faire de la modélisation UML. C'est toujours mieux d'utiliser des standards reconnus.
Quelques liens pour apprendre :
- http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML.html
- http://www.agilemodeling.com/essays/umlDiagrams.htm
Tu peux aussi trouver de bons livres sur Amazon
Et un logiciel simple et gratuit pour faire des diagrammes :
- http://alexdp.free.fr/violetumleditor/page.php
Tu peux aussi utiliser argoUML si tu veux générer du code.
Voilà ce que je conseille :
- Faire une analyse des besoins et un cahier des charges
- Commencer par Use-Case pour montrer les acteurs et les fonctionnalités nécessaires
- Continuer avec des diagrammes Activity et Class pour découper le projet en classes et représenter la logique de l'application
- Continuer avec des diagrammes Sequence pour modéliser les actions en détail
- Implémenter et bien documenter son code, garder les diagrammes à jour par rapport au code
Voilà ! J'espère que ça aide.
mario002e
Messages postés
82
Date d'inscription
samedi 29 septembre 2007
Statut
Membre
Dernière intervention
8 mai 2012
6
13 sept. 2010 à 17:42
13 sept. 2010 à 17:42
Merci pour votre intervention que je trouve très suffisante pour amorcer le projet. Voici en quelques lignes l'analyse des besoins:
- L'administration des comptes clients
- Le traitement des données GPS
- La géolocalisation
- La gestion des flottes et leurs interfaçages
- La gestion des zones géographiques et de surveillance
1.1. La gestion des clients
Cette partie permet de gérer les clients abonnés en fonction de leurs abonnements. Pour des raisons de sécurité, chaque utilisateur d'une compagnie client doit s'identifier en saisissant le nom de sa compagnie, son nom d'utilisateur et son mot de passe.
Les principales fonctionnalités sont les suivantes :
- La création d'un nouveau client;
- La modification des paramètres d'un client;
- La consultation de la liste des clients;
- La résiliation de contrat;
1.2. Le traitement des données GPS
Les véhicules sont équipés d'un boîtier (traceur) qui transforme les signaux émis par les satellites afin d'obtenir une position et une vitesse, un ensemble d'outils et de capteurs complémentaires vont permettre non seulement de récupérer d'autres types d'informations mais également de communiquer avec le véhicule. Les informations sont transmises du boîtier vers le serveur distant par GPRS utilisant le protocole TCP. Ces informations sont interceptées grâce à un module socket que nous programmerons en java fonctionnant en multithread, puis traitées et mises à la disposition des utilisateurs.
1.3. La géolocalisation
Il s'agit de la conception d'une application web de géolocalisation permettant :
- De localiser en temps réel le positionnement, le parcours et des informations relatives aux flottes de véhicules, les équipes ou les marchandises sur une carte Google
- De visualiser en temps réel le parcours des traceurs sur une carte Google
- D'identifier l'état marche/arrêt ainsi que la vitesse du véhicule, du conteneur ou du personnel
- D'éditer et de recevoir par e-mail un rapport statistique sur les déplacements effectués et les vitesses atteintes par le véhicule, le conteneur ou le personnel
- De réaliser un web chat pour apporter un soutien technique nécessaire à l'installation des traceurs ainsi qu'à la prise en main
1.4. La gestion des zones
- Les lieux géographiques
Google vient de publier une nouvelle méthode qui manquait à Google Maps : le Reverse Geocoding. L'intérêt de ce dernier est de rendre plus compréhensible une position sur terre. Une latitude et une longitude ne sont pas réellement des informations que tout le monde peut comprendre facilement, alors qu'une adresse est quelque chose de courant. La seule chose qui manque est l'intégration de la précision de la position. Ainsi, nous devons réaliser un module permettant à un administrateur client d'ajouter ses propres points ou zones privées. Ces lieux seront affichés dans la partie géolocalisation lors de la consultation par un membre de la compagnie de cet administrateur.
- Les zones de surveillance
Différentes zones géographiques peuvent être définies, représentant par exemple un chantier, un parking ou une ville. Ce principe, appelé "géofencing", permet de déclencher des actions spécifiques lorsqu'un véhicule franchit les limites de ces zones.
Les zones peuvent être simples allant de simples triangles ou carrés à des formes très complexes (polygones convexes ou concaves).
Les principales fonctionnalités sont les suivantes :
- La création d'un lieu incluant les outils de dessin sur la carte géographique;
- La modification d'un lieu;
- La suppression d'un lieu;
- La consultation des lieux;
- L'association des traceurs d'un compte aux zones de surveillance
Cette analyse m'a permis de déceler 4 acteurs principaux:
L'administrateur système :
L'administrateur client:
L'utilisateur:
Le traceur
* Chaque acteur doit passer par une étape d'authentification avant d'accéder aux ressources dont il a droit.
* Les administrateurs peuvent ajouter, modifier ou supprimer des acteurs.
* L'administrateur système gère tous les clients et administre le système
* L'administrateur du côté client peut gérer les alarmes, les lieux géographiques et les flottes de véhicules selon le type d'abonnement choisi par la compagnie.
* Les administrateurs et les utilisateurs peuvent consulter la partie géolocalisation
Cependant j'ai l'impression que les différentes fonctionnalités du projet ne collaborent pas toutes ensemble.
J'ai également des problèmes au niveau du diagramme d'activité car à ce niveau, je n'ai pas tellement de procédures compliquées pour chaque opération si ce n'est ajouter, modifier et supprimer et consulter. Toutes ces opérations ont déjà été transcrites en diagramme de séquence et je me demande s'il n'y aura pas de redondance.
Je vous prie donc de venir à mon secours!
- L'administration des comptes clients
- Le traitement des données GPS
- La géolocalisation
- La gestion des flottes et leurs interfaçages
- La gestion des zones géographiques et de surveillance
1.1. La gestion des clients
Cette partie permet de gérer les clients abonnés en fonction de leurs abonnements. Pour des raisons de sécurité, chaque utilisateur d'une compagnie client doit s'identifier en saisissant le nom de sa compagnie, son nom d'utilisateur et son mot de passe.
Les principales fonctionnalités sont les suivantes :
- La création d'un nouveau client;
- La modification des paramètres d'un client;
- La consultation de la liste des clients;
- La résiliation de contrat;
1.2. Le traitement des données GPS
Les véhicules sont équipés d'un boîtier (traceur) qui transforme les signaux émis par les satellites afin d'obtenir une position et une vitesse, un ensemble d'outils et de capteurs complémentaires vont permettre non seulement de récupérer d'autres types d'informations mais également de communiquer avec le véhicule. Les informations sont transmises du boîtier vers le serveur distant par GPRS utilisant le protocole TCP. Ces informations sont interceptées grâce à un module socket que nous programmerons en java fonctionnant en multithread, puis traitées et mises à la disposition des utilisateurs.
1.3. La géolocalisation
Il s'agit de la conception d'une application web de géolocalisation permettant :
- De localiser en temps réel le positionnement, le parcours et des informations relatives aux flottes de véhicules, les équipes ou les marchandises sur une carte Google
- De visualiser en temps réel le parcours des traceurs sur une carte Google
- D'identifier l'état marche/arrêt ainsi que la vitesse du véhicule, du conteneur ou du personnel
- D'éditer et de recevoir par e-mail un rapport statistique sur les déplacements effectués et les vitesses atteintes par le véhicule, le conteneur ou le personnel
- De réaliser un web chat pour apporter un soutien technique nécessaire à l'installation des traceurs ainsi qu'à la prise en main
1.4. La gestion des zones
- Les lieux géographiques
Google vient de publier une nouvelle méthode qui manquait à Google Maps : le Reverse Geocoding. L'intérêt de ce dernier est de rendre plus compréhensible une position sur terre. Une latitude et une longitude ne sont pas réellement des informations que tout le monde peut comprendre facilement, alors qu'une adresse est quelque chose de courant. La seule chose qui manque est l'intégration de la précision de la position. Ainsi, nous devons réaliser un module permettant à un administrateur client d'ajouter ses propres points ou zones privées. Ces lieux seront affichés dans la partie géolocalisation lors de la consultation par un membre de la compagnie de cet administrateur.
- Les zones de surveillance
Différentes zones géographiques peuvent être définies, représentant par exemple un chantier, un parking ou une ville. Ce principe, appelé "géofencing", permet de déclencher des actions spécifiques lorsqu'un véhicule franchit les limites de ces zones.
Les zones peuvent être simples allant de simples triangles ou carrés à des formes très complexes (polygones convexes ou concaves).
Les principales fonctionnalités sont les suivantes :
- La création d'un lieu incluant les outils de dessin sur la carte géographique;
- La modification d'un lieu;
- La suppression d'un lieu;
- La consultation des lieux;
- L'association des traceurs d'un compte aux zones de surveillance
Cette analyse m'a permis de déceler 4 acteurs principaux:
L'administrateur système :
L'administrateur client:
L'utilisateur:
Le traceur
* Chaque acteur doit passer par une étape d'authentification avant d'accéder aux ressources dont il a droit.
* Les administrateurs peuvent ajouter, modifier ou supprimer des acteurs.
* L'administrateur système gère tous les clients et administre le système
* L'administrateur du côté client peut gérer les alarmes, les lieux géographiques et les flottes de véhicules selon le type d'abonnement choisi par la compagnie.
* Les administrateurs et les utilisateurs peuvent consulter la partie géolocalisation
Cependant j'ai l'impression que les différentes fonctionnalités du projet ne collaborent pas toutes ensemble.
J'ai également des problèmes au niveau du diagramme d'activité car à ce niveau, je n'ai pas tellement de procédures compliquées pour chaque opération si ce n'est ajouter, modifier et supprimer et consulter. Toutes ces opérations ont déjà été transcrites en diagramme de séquence et je me demande s'il n'y aura pas de redondance.
Je vous prie donc de venir à mon secours!
mario002e
Messages postés
82
Date d'inscription
samedi 29 septembre 2007
Statut
Membre
Dernière intervention
8 mai 2012
6
14 sept. 2010 à 16:15
14 sept. 2010 à 16:15
Une fois encore, je vous remercie!
En fait toutes ces applications sont visibles par une interface web centralisée sauf le module de traitement java qui enregistre les différentes positions des mobiles.
SVP, Selon vous, les cas d'utilisation sont-ils bien analysés et cohérents?
En fait toutes ces applications sont visibles par une interface web centralisée sauf le module de traitement java qui enregistre les différentes positions des mobiles.
SVP, Selon vous, les cas d'utilisation sont-ils bien analysés et cohérents?
blackdragon5040
Messages postés
63
Date d'inscription
samedi 6 mars 2010
Statut
Membre
Dernière intervention
8 décembre 2011
11
14 sept. 2010 à 12:57
14 sept. 2010 à 12:57
Le projet semble assez complexe est est apparemment fragmenté carrément en plusieurs applications différentes, mais qui utilisent les mêmes données (par exemple une base de données). Les systèmes ne communiqueraient donc pas forcément tous ensemble. Est-ce que toutes ces informations sont visibles par une interface web centralisée ou sont accessibles par différentes applications ?
Les diagrammes d'activité servent à modéliser la logique d'une fonctionnalité (exemple: ajouter un utilisateur). Ils doivent montrer simplement les cas possibles et le déroulement des opération. Pour les opérations simples (ajout, suppression etc), ils ne sont pas forcément pertinents (c'est à vous de voir).
Pour ma part, j'utilise plutôt les diagrammes de séquences pour modéliser le dialogue entre les objets dans mes applications. On peut aussi l'utiliser pour montrer le dialogue entre des sous-systèmes d'une application.
Normalement, il ne devrait pas y avoir trop de redondance, mais parfois on a les mêmes actions décrites différemment.
Je ne peux malheureusement pas vous aider plus que cela. J'espère que d'autres apporteront des éclaircissements.
Les diagrammes d'activité servent à modéliser la logique d'une fonctionnalité (exemple: ajouter un utilisateur). Ils doivent montrer simplement les cas possibles et le déroulement des opération. Pour les opérations simples (ajout, suppression etc), ils ne sont pas forcément pertinents (c'est à vous de voir).
Pour ma part, j'utilise plutôt les diagrammes de séquences pour modéliser le dialogue entre les objets dans mes applications. On peut aussi l'utiliser pour montrer le dialogue entre des sous-systèmes d'une application.
Normalement, il ne devrait pas y avoir trop de redondance, mais parfois on a les mêmes actions décrites différemment.
Je ne peux malheureusement pas vous aider plus que cela. J'espère que d'autres apporteront des éclaircissements.
