Discussion :

[vleleu]

Bonjour,
Etant débutant, j'aimerais me familiariser avec la méthodologie en utilisant un exemple que je maitrise:
Création d'un composant spécifique sous Joomla 3 (PHP/MVC/CRUD & SEARCH)

Question 1:
Lorsque l'on utilise un Framework (Joomla ou autre) doit-on le représenter dans les différents diagrammes UML ? (cas d'utilisation, classes etc.)

Question 2:
Lorsque l'on effectue des taches de gestion (CRUD+SEARCH) peut-on faire une représentation abstraite sur un diagramme principal des cas d'utilisation ex: Gérer les Professeurs et créer sur d'autres diagrammes UC détaillés. Exemple: UC Search

Le composant que je souhaite créer sera basic
- CRUD & SEARCH Professeurs
- CRUD & SEARCH Classes
- Maping Professeurs/Classes

- Utilisateurs:
(*) User
(*) Administrator
- Accès:
(*) FrontEnd
(*) BackEnd

Merci d'avance

[thierryc]

Bonjour,

Question 1:
En général, quand on utilise un "framework" externe, on peut le représenter par un ou plusieurs paquetages dans le diagramme de composants, d'architecture (paquetages) ou de déploiement, et représenter par des classes les composants utilisés et les classes créées à l'intérieur du framework. Les diagrammes de séquences sont très utiles pour documenter les interactions standards du framework que l'on utilise, si les séquences ne sont pas déjà fournies dans la documentation du framework.
Par ailleurs, si vous avez un outil de rétro-conception, il peut être utile de l'utiliser sur le source du "framework" pour y naviguer.

Question 2:
Cela dépend de l'usage de vos cas d'utilisations: pour vos utilisateurs et clients, ce qui gouverne c'est leur besoin de compréhension et de précision dans l'expression du besoin. L'emploi du jargon informatique doit être le plus limité possible.

Si vous destinez vos cas d'utilisations à vos architectes et développeurs, vous pouvez très bien définir plusieurs cas d'utilisations génériques (ou des séquences) et les instancier sur des objets, par exemple un diagramme de classe illustrant les objets du domaine.

Il faut rester savoir rester léger, lisible et ne pas y passer trop de temps.
En espérant que cette réponse puisse aider...
De manière générale sur ce forum, il vaut mieux proposer des diagrammes pour avoir un meilleur retour.

[vleleu]

Bonjour,
merci pour ton aide.
Je te fait un point avant d'attaquer le diagramme de classe de mon "UML HelloWorld" ;-)

1- Je travaille avec le Framework Joomla 3.7

2- J'ai créé un composant basic uniquement côté Backend
2.1 Une seule table: #__profs (id,state,nom,prenom)
2.2 Vues
Vue: Gestion des professeurs
Vue: Edition d'un professeur
-> voir copie écran

3- Pour le diagramme des cas d'utilisation
3.1 un seul acteur: Administrateur
3.2 cas d'utilisation: "Gestion de la liste des professeurs" & "Edition d'un professeur"
Cela devrait me permettre de décrire plus facilement les deux uc avec deux diagrammes d'activité

4- Diagramme de classes
Dans le composant les classes sont créées par extension des classes existantes dans le Framework
Exemples:
4.1 Table
class FaculteTableprofesseur extends JTable
{
.../...
}

4.2 Vue
class FaculteViewProfesseurs extends JViewLegacy
{
.../...
}

4.3 Modèle
Class FaculteModelProfesseurs extends JModelList
{
.../...
}

4.4 Controlleur
class FaculteControllerProfesseurs extends JControllerAdmin
{
.../...
}

Question: dans le diagramme de classes tu ferais apparaitre une ou deux classes ?
Exemple:
class FaculteTableprofesseur
ou
class FaculteTableprofesseur & class JTable

Vincent

Bonjour,

Question 1:
En général, quand on utilise un "framework" externe, on peut le représenter par un ou plusieurs paquetages dans le diagramme de composants, d'architecture (paquetages) ou de déploiement, et représenter par des classes les composants utilisés et les classes créées à l'intérieur du framework. Les diagrammes de séquences sont très utiles pour documenter les interactions standards du framework que l'on utilise, si les séquences ne sont pas déjà fournies dans la documentation du framework.
Par ailleurs, si vous avez un outil de rétro-conception, il peut être utile de l'utiliser sur le source du "framework" pour y naviguer.

Question 2:
Cela dépend de l'usage de vos cas d'utilisations: pour vos utilisateurs et clients, ce qui gouverne c'est leur besoin de compréhension et de précision dans l'expression du besoin. L'emploi du jargon informatique doit être le plus limité possible.

Si vous destinez vos cas d'utilisations à vos architectes et développeurs, vous pouvez très bien définir plusieurs cas d'utilisations génériques (ou des séquences) et les instancier sur des objets, par exemple un diagramme de classe illustrant les objets du domaine.

Il faut rester savoir rester léger, lisible et ne pas y passer trop de temps.
En espérant que cette réponse puisse aider...
De manière générale sur ce forum, il vaut mieux proposer des diagrammes pour avoir un meilleur retour.

[bruno_pages]

Bonjour,

Question: dans le diagramme de classes tu ferais apparaitre une ou deux classes ?
Exemple:
class FaculteTableprofesseur
ou
class FaculteTableprofesseur & class JTable

Les deux, le fait que FaculteTableprofesseur extends JTable est une information importante qui mérite d'être montrée dans un diagramme de classes non ?