Discussion :

[Okaryn]

Hello tout le monde,

Ayant eu récemment une formation Java Conception Objet avec une approche de l'utilisation de l'UML, je me suis dit que j'allais ré-écrire un de mes programmes, dont j'ai perdu les sources, de façon à mettre en pratique ces cours.

Il s'agit d'une application de gestion de mot de passe, stockés sous forme de fiches dans des catégories. Les catégories étant paramétrables (nombre et type de champs variables).

J'ai donc commencé, de façon un peu simpliste, le diagramme de classe (dur dur de ne pas penser avec les anciens réflexes) et je bloque un peu sur les parties "description des catégories" et "Fiches", pour faire le lien sur les types de champs possibles. Je pense utiliser une énumération, les types étant fixes, dans la description des catégories (plutôt que d'y coller un objet champ) et dans un attribut de la classe Champ pour facilement le lien entre les 2.

J'ai mis en pièce jointe ce que j'ai finalement pondu après des heures et des heures de triturage de méninges et en faisant abstraction de ce que j'avais pu mettre en place dans le précédent programme

Est-ce que je suis sur une bonne voie pour continuer et bien dois-je revoir cette partie ?

Il manque quasiment toutes les fonctions au niveau des classes, c'est normal, je préfère y aller pas à pas et me poser de temps en temps pour être certain de ne pas partir en cagague

Pour une idée du programme dont je parle, voir ici

Merci

[hed62]

En regardant vite fait, je vois une série de détails :

La relation Entre fiche et Catégorie me semble inversée : c'est la catégorie qui est un agrégat de Fiche, non l'inverse pour moi.

Sur les Rôle des relations, tu met des verbe, j'avoue que personnellement je met plutôt des noms, parceque cela rend copmpte du nom de la collection que l'on mettra dans le code.

Exemple :

CATEGORIE <>-------------------------lesFiches-*- FICHE

Donnera (volontairement simplifié):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class CATEGORIE
{
  private List lesFiches;
}

Toutes tes relations sont des agrégations, c'est peut être justifié, mais c'est aussi ûn choix "par défaut" donc potentiellement mal adapté. A toi de voir

Puisque l'application gère les mots de passes, à quoi servent les fiches, et leurs champs ?

Sinon, pour y voir plus clair au niveau méthode : généralement on commence par les diagrammes de use case, qui dégagent les axes fonctionnels, puis des diagrammes de séquence système (2 acteur : l'utilisateur et le "système") puis un diagramme de classes candidates.

Enfin, on commence à rejoindre les deux en construisant en parrallèle les diagrammes de séquences détaillés et le diagramme de classes. On obtient ainsi un bon nombre des méthodes des classes.

Bon courage

[Okaryn]

Merci pour cette réponse.

En effet, la relation est bien inversée entre les catégories et les fiches. J'étais parti sur le fait que c'est la fiche qui sait à quelle catégorie elle appartient, alors qu'en fait c'est la catégorie qui connait ses fiches. Du coup, je pense qu'il faudrait que je retire l'attribut "categorie" de Fiche pour ajouter, comme tu le dis, un "lesFiches" dans Categorie.

Quoique, en corrigeant mon diagramme, je m'aperçois que je m'étais dis que ce sont les utilisateurs qui possèdent les fiches, et que les fiches appartiennent à une catégorie. D'où ma confusion dans le diagramme je pense. J'ai gardé le réflexe de me dire qu'il y allait donc y avoir 2 fois les fiches : 1 fois dans Catégorie et une fois dans Utilisateur. Je commence à m'embrouiller

Pour la suite, un peu plus tard, ma femme m'attend pour manger Mais j'ai des questions qui me viennent à l'esprit

[Suite...]

Après un bon repas, les idées sont plus claires

J'ai corrigé/simplifié le DC en prenant en compte tes remarques. Quelques agrégations ont été supprimées et 2 ont été remplacées par des dépendances (au niveau de l'énumération des types). J'ai réussi à ne pas penser au modèle de la base de données, où la table "fiches" contenait forcément une colonne "catégorie" et du coup je devais avoir cet attribut dans la classe Fiche. En objet, je pense que c'est l'agrégation Catégorie<>-fiche qui permettra d'alimenter cette colonne dans la base de données.

Pour ta question sur les champs, j'ai un peu trop réduit le champ d'action du programme. A la base, il sert pour les mots de passes, mais l'utilisateur peut donner des informations supplémentaires aux fiches. Par exemple, pour une catégorie "Sites" : le nom, l'url, le login et le mdp. Pour une catégorie "Cartes bleues" : le numéro, le code, la date d'expiration, le code au verso et le nom du porteur. Etc.... C'est cette souplesse, associé au niveau de sécurité élevé, qui plait aux utilisateurs.

Pour les autres diagrammes, malheureusement la formation n'a fait qu'un bref survol dessus. Car en tant que développeurs, nous sommes censés recevoir directement ces diagrammes pour nous focaliser sur le DC et le DS. D'ailleurs, sur la seconde partie de la formation, on passait du cahier des charges directement au DC.

Encore merci pour ton avis, ces petites pistes m'ont bien aidé. Surtout qu'en ne souhaitant pas être expert UML (juste pour mon usage perso), j'ai pas trop l'envie d'investir dans des cours/bouquins juste pour 1 application personnelle

[hegros]

Pour revenir sur les rôles des classes, il est possible aussi d'ajouter des stéréotypes comme <List>champs pour la relation entre ETypeChamps et Champs.

Tu peux aussi stéréotyper(avec boundary) les unités de dialogues (comme la fiche)

En terme de conception cela me parait bizar de ne pas voir de controleur et lier directement categorie à fiche.

[Okaryn]

Merci Hegros pour ta réponse.

Je ne comprend pas ta première remarque. La classe Champ ne peut être que d'un seul type ETypeChamp. Et l'attribut champs de Fiche contient une liste de Champ.

Pour la seconde remarque, tu parles de créer une interface dont hériterait Fiche c'est ça ? Quel en serait l'intérêt ?

Enfin, dans ma tête de développeur, c'est Catégorie qui est le contrôleur de Fiche : Utilisateur demande à Categorie de se créer une nouvelle Fiche.
Mais en écrivant littéralement le processus, c'est Utilisateur qui crée une Fiche dans Categorie. C'est peut être là qu'il y a un problème de représentation ?

[hegros]

Pour la première remarque en effet oublie.

Ensuite ce qui me gêne c'est que Catégorie contient des Fiches hors c'est ce qu'on nous apprends à ne pas faire en conception soit un objet du domaine qui contient un objet de type UI.

Un controleur c'est une classe artificielle d'informaticien Catégorie ne peut pas en être un puisqu'il représente un concept connu et utilisé par les utilisateurs.

Ensuite pour toutes les classes de type Champs j'ai l'impression aussi qu'il s'agit de classe dialog ? En fait sans stéréotype et sans connaitre l'appli ce n'est pas clair (en tout cas pour moi)

[Okaryn]

Sur le diagramme, je n'ai représenté que des classes métier, aucunement des classes de dialogue (interface utilisateur si je t'ai bien compris). J'essaie d'appliquer le modèle des 3 couches. Là je suis sur la partie du milieu, la plus importante à mes yeux.

Il y aura bien des interfaces (contrôleurs), pour dialoguer avec l'IHM d'une part et les données persistantes de l'autre.

Pour les classes ChampXxxx, j'ai prévu tout de suite la possibilité que chaque type de champ puisse avoir des fonctions différentes, comme par exemple une procédure de cohérence du contenu (règle fonctionnelle), en utilisant une fonction "verifierContenu" dans chaque classe, plutôt qu'une globale dans la classe Champ avec des tests conditionnels à gogo.

Pour décrire les classes du diagramme, et leur fonctionnement :

Un utilisateur [Utilisateur] crée des catégories [Catégorie], utilisables par tous les utilisateurs. Une catégorie est paramétrable au niveau du contenu possible, grâce à des champs [DescriptionChamp] de types prédéfinis [ETypeChamps] et d'un libellé qui sera affiché pour décrire la zone de saisie (voir image).
L'utilisateur peut ensuite créer des fiches [Fiche], non visibles par les autres utilisateurs, qui sont rangées dans une catégorie. Le contenu de la fiche est stocké dans des champs [Champ] correspondant à la description de la catégorie (voir image).

Sur le diagramme, il me reste surtout un doute sur la relation entre les 3 classes [Utilisateur], [Categorie] et [Fiche]. Est-ce que je garde ce que j'ai fait ou bien je rajoute un lien entre Fiche et Utilisateur, facilitant ainsi le listage des fiches de l'utilisateur sans devoir passer par les catégories. Mais dans ce dernier cas, j'augmente le nombre de relations, et on m'a indiqué qu'il fallait les réduire au maximum.

Merci en tout cas de tes remarques, cela me fait me poser des bonnes questions

[hegros]

... Mais dans ce dernier cas, j'augmente le nombre de relations, et on m'a indiqué qu'il fallait les réduire au maximum.

Cela dépend il faut user du bon sens. Si augmenter le nombre de relation augmente la complexité alors cherchez à les réduire au maximum. Si augmenter le nombre de relation simplifie la complexité alors il n'y a à priori pas de problème au contraire.

Cependant c'est surtout les relations entre couche UI et application et application et domaine qui sont intéressantes en tout cas pour ma petite explictation du dessus...



Pour le reste je t'en dirais plus plus tard