Discussion :

[Spout]

Bonjour à tous,

Suite à ma précédente discussion, je suis arrivé au diagramme d'UC en PJ. Est-il correct?

Je commence donc avec la description du premier UC, Ajouter un profil:

Titre: Ajouter un profil
Résumé: Ce cas d'utilisation permet à un Utilisateur d'ajouter un profil dans la base de données.
Acteurs: Utilisateur (principal), BDD (secondaire)
Date de création: 28/09/2008
Date de mise à jour: 29/09/2008
Version: 1.0

Préconditions:
- Le PC est allumé et fonctionnel
- La base de données est présente dans le répertoire de l'application.
- Aucune fenêtre de l'application n'est ouverte.

Scénario nominal:
1. L'utilisateur fait un clic droit sur l'icône de l'application dans la barre des tâches.
2. Le menu s'affiche au dessus de l'icône.
3. L'utilisateur sélectionne l'item "Ajouter un profil" du menu.
4. La fenêtre de saisie du nouveau profil s'affiche.
5. L'utilisateur remplit les champs obligatoires de la fenêtre et valide.
6. Le système interroge la base de donnée si un profil existe déjà sous ce nom.
7. La base de données informe le système qu'aucun profil n'existe sous ce nom.
8. Le système envoie à la base les données du nouveau profil.
9. La base de données confirme l'enregistrement du nouveau profil.
10. Le système confirme à l'utilisateur que le nouveau profil a été ajouté.
11. L'utilisateur referme la fenêtre de confirmation et la fenêtre d'ajout.

Enchaînements alternatifs:
A1 - Données incomplètes. Cet enchaînement démarre au point 4 du scénario nominal.
5. L'utilisateur ne saisit pas la totalité des champs obligatoires et valide.
6. Le système informe l'utilisateur que des champs obligatoires ne sont pas remplis.
7. L'utilisateur referme la fenêtre d'avertissement.
8. Les champs incomplets sont mis en avant.
Le scénario nominal reprend à l'étape 4, avec les champs pré-remplis des valeurs correctes de la tentative précédente.
-
A2 - Profil existant. Cet enchainement démarre au point 6.
7. La base de données indique qu'un profil existe déjà à ce nom.
8. Le système informe l'utilisateur qu'un profil existe déjà sous ce nom.
9. L'utilisateur ferme l'avertissement.
10. Les champs clés (nom + prénom ET/OU Pseudo) sont mis en avant.
Le scénario nominal reprend au point 5.

Enchaînements d'erreur:
Aucun

Postconditions:
La base de données contient un profil en plus.

Temps de réponse: l'ajout dans la base de données doit s'effectuer dans la seconde à partir du moment où l'utilisateur valide le formulaire d'ajout.
Disponibilité: l'ajout de profil est accessible à n'importe quel moment, du moment que le PC sur lequel il est installé est allumé.

IHM:
La fenêtre d'ajout d'un profil doit contenir:
- Nom + Prénom (obligatoire) ET/OU Surnom (obligatoire)
- Jour de naissance (obligatoire)
- Mois de naissance (obligatoire)
- Année de naissance (facultatif)
- Numéro de téléphone (facultatif)
- Adresse (facultatif)
- Rappel (obligatoire) (Heures + Jours + Mois)

J'ai des doutes sur certains points:

• Dans l'enchainement alternatif 2, je veux proposer à l'utilisateur de modifier/supprimer le profil existant après l'avoir consulté. Dois-je rajouter cet aspect dans le diagramme, du style Editer un profil et Supprimer un profil extends Ajouter un profil?
• La postcondition est-elle nécessaire étant donné qu'elle concerne un acteur extérieur au système?

N'hésitez pas à me corriger ou me parler d'une manière différente d'envisager certains points.

J'ai peur d'être trop exhaustif sur certains aspects du séquencement, et pas assez sur d'autres.
Qu'en pensez-vous?

Merci d'avance.

[wiztricks]

Personnellement, je séparerais la problématique métier (ajouter un profil) de celle de l'IHM (présentation).

L'UC "Ajouter un profil" pourrait commencer après que l'utilisateur l'ait demandé, les étapes 1-3 pourraient remonter dans les pré-conditions.
Techniquement, on peut étendre "Ajouter" avec "Détruire" ou "Modifier" le profil sélectionné modulo que cela reste cohérent avec le reste.

Je ne comprend pas trop l'intérêt de matérialiser "la Base de Donnée" comme acteur externe... N'est ce pas un des composants de l'application?
- W

[Spout]

Personnellement, je séparerais la problématique métier (ajouter un profil) de celle de l'IHM (présentation).

Pour toi les besoins d'IHM ne doivent pas apparaître dans la description des UC?

Je ne comprend pas trop l'intérêt de matérialiser "la Base de Donnée" comme acteur externe... N'est ce pas un des composants de l'application?

Si si
Tu le matérialiserais en tant qu'acteur interne? Ou pas matérialisé du tout?

[hed62]

Pour toi les besoins d'IHM ne doivent pas apparaître dans la description des UC?

Effectivement, on ne place pas les spécification ihm sur les UC. Les UC doivent pouvoir etre transposable d'une appli console à un client léger

La base de données, également, n'est pas à matérialiser.

[wiztricks]

Envoyé par wiztricks Voir le message
Personnellement, je séparerais la problématique métier (ajouter un profil) de celle de l'IHM (présentation).

Pour toi les besoins d'IHM ne doivent pas apparaître dans la description des UC?

Je dirais que l'UC décrit une fonctionnalité métier (quoi) qui doit être si possible indépendante de l'implémentation et de l'IHM (comment, avec).
A cette étape, il est préférable de se concentrer sur pré-requis, post-conditions, séquence des opérations et les relations avec d'autres UC.

Une fois cette architecture d'ensemble mieux définie vont pouvoir être définis les différents composants de l'applications. L'IHM est un de ces composants (au même titre que la base de donnée).

Suivant le projet, nous pourrions avoir à créer un IHM de type GUI avec un look&feel spécifique à un client donné et une interface CLI (mode ligne).
L'interface CLI pouvant permettre la séparation des tests à effectuer sur l'application de la mise au point du GUI.

Si nous intégrons la description de l'IHM dans l'UC, il faudra avoir un UC pour chaque type d'IHM... Beurk.

Envoyé par wiztricks Voir le message
Je ne comprend pas trop l'intérêt de matérialiser "la Base de Donnée" comme acteur externe... N'est ce pas un des composants de l'application?

Si si
Tu le matérialiserais en tant qu'acteur interne? Ou pas matérialisé du tout?

La fonction de la base de donnée est relative à la "persistence" (=QUOI). Ie tu as envies de retrouver demain les informations enregistrées aujourd'hui ou la semaine dernière.

Cela dit "comment" interfacer la base de donnée avec l'application pourra se faire classiquement avec des ordres SQL ou en utilisant un ORM qui mettra en correspondance les "objets" de l'application et les tables de la base.

Dans les deux cas, nous aurons la fonction de persistance mais suivant la méthode choisie, ce sera plus ou moins transparent côté code.

Note: Dans ton UC tu précises que la base de donnée est dans le répertoire application du PC de l'utilisateur. Un fichier plat pourrait suffire.

- W

[hegros]

Pour moi tes UC n'en sont pas.

ajouter, supprimer, modifier.. ce sont des scénarios d'un cas d'utilisation "gérer les utilisateurs"

Normalement les CRUB (create, read, update...) ne sont jamais des UC, ce sont des fonctionnalités déja entendues.


Tu peux représenter tous ces scénarios dans un seul diagramme d'activité

[wiztricks]

Pour moi tes UC n'en sont pas.

ajouter, supprimer, modifier.. ce sont des scénarios d'un cas d'utilisation "gérer les utilisateurs"

Normalement les CRUB (create, read, update...) ne sont jamais des UC, ce sont des fonctionnalités déja entendues.


Tu peux représenter tous ces scénarios dans un seul diagramme d'activité

Les UC sont un outil de dialogue avec le client. Représenter ou pas les extensions C, R, U, D de ce que nous appellerions "users profile management" dépendra de ce dialogue.

Une fois les UC collectés et autres artifacts collectés, il va falloir identifier les différents componsants de l'application.
A cette étape, nous définirons sans doute le composant "users profile management". Comme il assure une fonction de persistence, nous nous poserons des questions côté CRUD à ce moment.
A défaut, l'application risque d'être incomplète.
C'est une étape nécessaire qui fait que je n'adhère pas du tout "à des fonctionnalités entendues".
- W

[hegros]

C'est une étape nécessaire qui fait que je n'adhère pas du tout "à des fonctionnalités entendues".
- W

Ce sont les activités d'ajout, de suppression etc qui sont des fonctionnalités entendues c'est valable pour des utilisateurs, des produits ce genre de chose. Il ne faut pas se plaindre ensuite de ne pas comprendre les besoins/exigences utilisateurs si on part de suite dans ce niveau de détail UC...

Une façon plus élégante, pour garder le dialogue avec les utilisateurs, c'est d'intégrer ces CRUB dans un diagramme d'activité mettant en évidence tous ces scénarios, en aucun cas les faire disparaître...

Maintenant c'est relatif quand je dis que ces UC n'en sont pas puisque je propose de passer par un diagramme d'activité qui n'est ni plus ni moins une instanciation des UC

[Spout]

Ce sont les activités d'ajout, de suppression etc qui sont des fonctionnalités entendues c'est valable pour des utilisateurs, des produits ce genre de chose. Il ne faut pas se plaindre ensuite de ne pas comprendre les besoins/exigences utilisateurs si on part de suite dans ce niveau de détail UC...

Seulement mon application ne fait que cela (voir le lien vers l'autre discussion donné dans le premier post). Si je ne décris pas ces comportements, la modélisation UML devient inutile pour mon projet?

[hegros]

Seulement mon application ne fait que cela (voir le lien vers l'autre discussion donné dans le premier post). Si je ne décris pas ces comportements, la modélisation UML devient inutile pour mon projet?

Non du tout, d'ailleurs je ne dis pas de ne pas les décrire (j'ai parlé de s'aider d'un diagramme d'activité regroupant tous les scénarios) mais plutot qu'il s'agit d'un groupe particulier pour lequel 1 UC est suffisant.


Il ne faut pas oublier que uml est un outil et qu'on s'en sert parce que modéliser graphiquement un logiciel est un facteur de réussite d'un projet c'est tout, il faut donc trouver un compromis dans la représentation en utilisant ce qui est disponible, pour la définition des besoins tu n'as pas que les UC, les diagrammes d'activité en font partie.


Voilà j'espère ne pas en avoir pas dis assez ou de trop

[wiztricks]

Seulement mon application ne fait que cela (voir le lien vers l'autre discussion donné dans le premier post). Si je ne décris pas ces comportements, la modélisation UML devient inutile pour mon projet?

Stop.
Comme tu l'as mentionné dans l'autre lien, tu apprends à modéliser avec UML et donc tu as tout à fait raison de poser des questions sur comment représenter cela ou ceci sans te poser de questions sur "l'utilité".

Le fait est qu'il n'est peut être pas indispensable d'utiliser l'artillerie lourde de la conception et de la modélisation UML pour un projet qui peut être réalisé en quelques jours!

Mais si on ne se fait pas violence sur de "petits" projets qui ne le méritent peut être pas, il ne sera pas facile d'aborder des projets plus touffus.

D'autant que tu as pu remarquer dans la discussions qu'il y a pas mal de débats parfois contradictoires sur ce qu'on doit raconter, pour qui, comment, où...
- W

[hegros]

Stop.
Comme tu l'as mentionné dans l'autre lien, tu apprends à modéliser avec UML et donc tu as tout à fait raison de poser des questions sur comment représenter cela ou ceci sans te poser de questions sur "l'utilité".

modéliser c'est trés bien mais quand on utilise UML on préfére quand même la modélisation graphique. Là ici on a une spécification textuelle formelle qui représente un scénario d'utilisation qui en UML peut se représenter aussi par d'autres diagrammes comme activité, état...

Le fait est qu'il n'est peut être pas indispensable d'utiliser l'artillerie lourde de la conception et de la modélisation UML pour un projet qui peut être réalisé en quelques jours!

Ce que l'on sait aussi c'est que la modélisation graphique est une des meilleures pratiques pour la conception de logiciel, on garde ainsi le lien avec les utilisateurs qui sont utilisé dans les diagrammes associés.

Cela ne veut certainement pas dire qu'il ne faut pas faire comme tu as fais en faisant une description formelle mais si tu débutes et que tu découvres UML je t'invite chaudement à t'essayer à d'autres diagrammes pour la modélisation des scénarios

[Spout]

Cela ne veut certainement pas dire qu'il ne faut pas faire comme tu as fais en faisant une description formelle mais si tu débutes et que tu découvres UML je t'invite chaudement à t'essayer à d'autres diagrammes pour la modélisation des scénarios

C'est en cours, un certain manque de temps m'empêchant de les terminer et de vous les soumettre .
Mais dès que j'ai ça je les postes ici!

[wiztricks]

Le fait est qu'il n'est peut être pas indispensable d'utiliser l'artillerie lourde de la conception et de la modélisation UML pour un projet qui peut être réalisé en quelques jours!

Ce que l'on sait aussi c'est que la modélisation graphique est une des meilleures pratiques pour la conception de logiciel, on garde ainsi le lien avec les utilisateurs qui sont utilisé dans les diagrammes associés.

Avant UML, modéliser signifiait dessiner des boites et des flèches sur un chart ou sur un tableau. Avec UML, c'est un peu plus formalisé mais il s'agit toujours de raconter une histoire pour s'assurer de ce qu'on veut et pouvoir en estimer les coûts.
S'il ne faut que quelques journées pour construire un prototype, ce pourra être un modèle valide (et pas besoin de graphiques, ni d'UML).
- W

[hegros]

Avant UML, modéliser signifiait dessiner des boites et des flèches sur un chart ou sur un tableau. Avec UML, c'est un peu plus formalisé mais il s'agit toujours de raconter une histoire pour s'assurer de ce qu'on veut et pouvoir en estimer les coûts.
S'il ne faut que quelques journées pour construire un prototype, ce pourra être un modèle valide (et pas besoin de graphiques, ni d'UML).
- W

Historiquement je n'ai rien à redire, les hommes de cromagnon aussi pouvait dessiner leur petite hute par terre avant de la construire.

Hors contexte historique soit on utilise un cadre méthodologie qui utilise UML et dans ce cas on s'y tient tout au long du projet autant que c'est nécessaire ou alors on n'en utilise pas de particuliére et alors fais comme tu veux.


Comme dis plus haut la modélisation graphique est une bonne pratique de la conception logiciel se serait dommage de s'en passer car il n'y a pas de doute entre un dessin graphique bien clair (sans surcharge inutile etc) et un texte brut et formelle, pour les lecteurs il n'y a pas de photo on comprends plus aisément un graphique.

[wiztricks]

Hors contexte historique soit on utilise un cadre méthodologie qui utilise UML et dans ce cas on s'y tient tout au long du projet autant que c'est nécessaire ou alors on n'en utilise pas de particuliére et alors fais comme tu veux.

Une méthodologie est un des outils pour réaliser des applications complexes de façon plus fiable. Si l'application a réaliser est "simple", on peut prendre des raccourcis sans trop de risques.

Comme dis plus haut la modélisation graphique est une bonne pratique de la conception logiciel se serait dommage de s'en passer car il n'y a pas de doute entre un dessin graphique bien clair (sans surcharge inutile etc) et un texte brut et formelle, pour les lecteurs il n'y a pas de photo on comprends plus aisément un graphique.

Je ne dis pas le contraire. J'essaie de souligner que l'objectif reste de construire une application et que les plans ne sont que des moyens pour y arriver.
- W