classe / séquence / C++

bonjour,

je souhaite traiter un petit problème en le modélisant en UML puis en l'implémentant en C++. J'utilise bouml pour ce faire. Je précide que je débute dans ce genre d'exercice.

Le problème:
le personnel d'une entreprise possède plusieurs niveaux d'accès aux différents site de celle-ci. Il possèdera donc un niveau. On lui attribuera également un nom et un prénom ainsi qu'un identificateur ID.
J'ai donc créé une classe Personnel, dérivant d'une classe Personne.

Ma base contiendra donc l'ensemble du personnel. J'ai une classe Base composée de Personnel. Le constructeur de la classe alimentera la base à partir d'un fichier disque alors que le destructeur sauvera la base dans le fichier.
L'implémentation de la composition se fait à l'aide d'un vector.

Pour l'instant, mon application est en mode console, donc l'interface est minimaliste. Il m'a semblé intéressant de créer une classe Interface afin d'assurer le dialogue avec l'administrateur.

J'ai créé un scénario permettant de créer un nouveau personnel. Je joins le diagramme de séquence auquel j'ai pensé.

Quelques question:
- mon modèle est-il correct?
- aurais-je du me passer de la classe interface?
- dans la classe Interface, j'ai un attribut de type Personnel. cela pose-t-il problème au niveau du modèle?

J'attends vos propositions avant de poser d'autres questions.

Merci d'avance.

Dans le diagramme de séquence on ne voit aucun paramètre passer dans les méthodes comme le nom ou le niveau et du coup cela est aussi inexistant dans ton diagramme de classe. Je pense que tu peux enrichir ton diagramme en indiquant les paramètres dans ton diagramme de séquence.


Pour l'interface je trouve que le nom est mal trouvé parce que c'est trop générique. Est-ce que tu pensais à une interface graphique si c'est le cas alors tu peux garder le nom mais ajoute un stéréotype boundary de tel façon à bien voir qu'il s'agit d'une interface graphique



Et je ne vois pas trop comment tu pourrais te passer d'une classe interface :koi:

merci pour ta réponse.

Citation:

---

Dans le diagramme de séquence on ne voit aucun paramètre passer dans les méthodes comme le nom ou le niveau et du coup cela est aussi inexistant dans ton diagramme de classe. Je pense que tu peux enrichir ton diagramme en indiquant les paramètres dans ton diagramme de séquence.

---

les paramètres apparaissent dans les classes. Dans le diagramme de séquence, j'ai pris l'option de ne pas les développer afin de ne pas trop alourdir.

Citation:

---

Est-ce que tu pensais à une interface graphique

---

pour l'instant, comme je l'indiquais dans mon premier message je suis en mode console.

En fait, je m'intéresse particulièrement à une utilisation pratique de l'uml, le code donc. J'ai quelques bouquins et des tutos trouvés sur le net et je trouve que cet aspect est trop peu développé.

C'est en passant à l'implémentation que je suis rendu compte du manque de pertinence de ma modélisation.

Citation:

---

Envoyé par jackk

les paramètres apparaissent dans les classes. Dans le diagramme de séquence, j'ai pris l'option de ne pas les développer afin de ne pas trop alourdir.

---

Non cela n'alourdit pas cela l'enrichit il faut trouver le juste milieu mais n'en mettre aucun ce n'est pas un juste milieu. Cela permet de mieux spécifier les méthodes de tes classes sinon à quel moment tu fais ce travail ? Quand tu fais le diagramme de classe ? Ce choix n'est pas judicieux.

En pratique une fois que mon diagramme de séquence est terminé alors le diagramme de classe est automatiquement déduit et complet c'est à dire avec les classes, les méthodes et leurs paramètres. En pratique il y a des allers retours entre séquence et classe pour améliorer l'ensemble

ok, j'ai fait quelques ajouts (voir fichiers joints).

cependant, j'ai dans Base un méthode creeEmploye afin d'ajouter un employé dans la base qui ne me satisfait pas trop. Quelle est la meilleure façon pour ajouter une instance de la classe Employé dans mon vecteur?

De plus, lorsque je génère le code C++, j'obtiens le message d'erreur ci-joint.

A+

C'est du design pattern (pattern créateur). Tu peux utiliser une Factory.

Je te conseille aussi de regarder le pattern forte cohésion parce que ta classe base fait un peu tout et n'importe (elle crée des employés, elle affiche, elle tri, elle fait des vérifications etc...).

Bref, cette classe Base n'a vraiment pas une forte cohésion il faut donc découper en d'autres classes. Regarde aussi le pattern de responsabilité unique.

Merci pour ta pateince.

Je ne m'attendais pas à devoir aborder les design pattern avant d'avoir un peu balayé les problèmes de base que je ne parviens pas à résoudre.

Pour la classe base par exemple, effectivement, elle fait beaucoup de choses, mais en admettant qu'elle ne fasse qu'ajouter, détruire et mettre à jour un employé, comment se passe par exemple la création d'un employé?

J'aimerais bien comprendre des choses aussi simples avant d'aller plus loin.

A+

La création d'un objet employé ou la création d'un enregistrement en base de donnée s? Si c'est en base de données alors il y a une méthode InsertEmployé qui prends en paramètre un employé puis dans cette méthode tu fais l'insertion selon la techno que tu utilises par exemple avec une procèdure stockée ou avec une requête sql brut ou par exemple en .NET avec Linq To Sql.

Mais grossomodo tu as une méthode InsertEmploye qui se charge de faire l'insertion en base. Assez classique.

ok.

Je crois que je me pose trop de questions. Je vais tester ça dès que possible.

A+

Pour ta question sur les pattern. Non ce n'est pas trop tôt car manifestement tu es en pleine phase de conception pas en phase d'analyse des spécifications fonctionnelles. Hors en conception c'est assez fondamental en effet.