Discussion :

[Laplix]

Bonjour tous,

Je viens de passer plusieurs journées à lire les cours et les forums sur le UML. Je débute dans ce domaine et, même si je suis à l'aise dans la POO, je demeure confus dans ce langage UML.

Voici le problème :

Je développe une librairie ORM et je veux utiliser les "best practices". Donc UML! J'ai identifié les utilisateurs (personnes humaines) de la librairie, à savoir

• Concepteurs de sites webs, amateurs et/ou professionnels
• Concepteurs d'application web 1.0 et web 2.0
• Concepteurs de "frameworks"

Ma question : Qui sont les acteurs de la librairie? Les personnes humaines qui vont l'utiliser ou les applications elles-mêmes?

Merci de me consacrer un peu de votre intelligence

[bruno_pages]

Bonjour,

Ma question : Qui sont les acteurs de la librairie? Les personnes humaines qui vont l'utiliser ou les applications elles-mêmes?

les acteurs sont les 'entitées' qui interagissent avec l'application à modéliser et qui sont en dehors de cette application

ce peut donc être des personne,s ou d'autres applications (par exemple un gestionnaire de BDs peut être un acteur secondaire)

les UCs décrivent ce que l'application doit faire, mais sans tenir compte de la façon dont elle va le faire ('quoi' mais pas 'comment')

[hegros]

Les acteurs de la librairie ce sont en fait les différents rôles que vont devoir jouer une ou plusieurs personnes avec elle.

Cela peut être des concepteurs, des développeurs, des responsables projets ...


Tu peux la faire en plusieurs itérations, la première fois on ne peut pas être toujours exhautive. Tout les rôles que tu identifieras (une personne physique peut avoir plusieurs rôles) seront en interaction avec les UC, on parlera même d'acteurs primaires et secondaires. Ce qui est important de dire c'est qu'un système peut aussi être un acteur, une autre librairie why not ?

En UML tu peux aussi modèliser les acteurs, essaie de nous poster ce que tu as fais

[wiztricks]

Bonjour

Ma question : Qui sont les acteurs de la librairie? Les personnes humaines qui vont l'utiliser ou les applications elles-mêmes?

Côté modélisation, la question est intéressante car effectivement nous ne savons pas trop par ou faire passer le couteau.

A la base, toutes les démarches doivent répondre à des questions simples:

• quoi? autrement dit les besoins métiers (qu'on exprime en général avec des UC)
• comment? les composants et les interfaces
• avec quoi, quand, où? la réalisation et le déploiement

Une librairie, c'est du "avec quoi" autrement dit du déploiement. Si elle pourra être visible "plus haut", dans les composants et les interfaces. Il est rare qu'elle monte jusqu'au besoins métiers(*).

Dit autrement, elles ne participent pas au "uses cases"... pour ce qui est des "acteurs"

Sauf qu'il n'est peut être pas inutile de faire un ou plusieurs UC pour des exemples d'utilisation (à l'intention du développeur/concepteur). Dans ce cas,on ira vite dans composants, interactions, déploiements. Il ne s'agit pas de conception à proprement parler mais d'exemples d'utilisation.

(*) Il arrive qu'une entreprise ait fait des choix technologiques. Dans ce cas, rester neutre peut être contre productif surtout lorsque les technos retenues sont plutôt "structurantes".

Le développeur qui souhaite utiliser cette librairie a des "besoins métiers". Nous pourrions en rendre compte via des UC dont il serait "acteur":

• comment enchaîner les opérations pour réaliser les traitements
• installer, compiler
• intégrer dans l'application (en tête, édition de liens)

Mais nous connaissons déjà ce que cela signifie côté "déploiement": tutoriels, manuel d'installation, d'utilisation,...

- W

[Laplix]

Ouf, messieurs, je n'étais vraiment pas "off" quand j'ai parlé d'intelligence

Je vous en remercie.

Pour les vrais Use Case graphiques, je viens tout juste de télécharger StarUML et ArgoUML et je dois avouer que je me bats un peu avec ma compréhension de ces logiciels et de tout ce vocabulaire

Un peu de contexte : La librairie est un ORM développé en PHP.

Mes cas d'utilisation sont tout de même assez simples, du moins je crois...

• créer une requête de lecture
• exécuter la requête ce qui retournera N occurences
• créer un objet correspondant à une (1) occurrence d'une (1) table de la BD
  
  • lire cet objet
  • manipuler les données de cet objet pour les enregistrer dans le SGBD

Le seul acteur que je voyais était "Application" quoique le web 2.0 demanderait peut-être du XML ou du JSON. De plus, selon ce que dit bruno_pages, les gestionnaires de bases de données peuvent également être des acteurs secondaires?

@wiztricks Si je comprends bien, une librairie n'a pas vraiment d'acteur? Les cas d'utilisation seraient plutôt une simulation de personnes physiques écrivant des applications et utilisant la librairie? Ai-je vraiment besoin de simuler cela?

bruno_pages semble dire que même des applications peuvent être des acteurs?

Pourrions-nous dire alors que j'ai, au fond, deux acteurs :

* un acteur traditionnel (site web traditionnel, application web traditionnelle, framework web traditionnel et même application GTK
* un acteur web 2.0 qui aura besoin de recevoir ses résultats dans un format XML ou JSON

Ou bien, effectivement, ma librairie n'a pas d'acteur et que je dois simplement me concentrer sur le design des classes elles-mêmes (interface, héritage, etc.) Et dans ce cas, ai-je vraiment besoin de faire des diagrammes UML???

Merci encore pour vos lumières.

[bruno_pages]

Pour les vrais Use Case graphiques, je viens tout juste de télécharger StarUML et ArgoUML

laisse tomber ArgoUML, de ce que je peu entendre de ses utilisateurs il n'est vraiment pas stable et se plante trop souvent

je me bats un peu avec ma compréhension de ces logiciels et de tout ce vocabulaire

l'informatique (les informaticiens) a toujours aimé compliquer les choses en amenant un nouveau vocabulaire le plus hermétique possible aux 'non initiés'

tu te fixes trop de règles en ce qui concerne tes acteurs, encore une fois un acteur est juste "quelque chose" interagissant avec ton système, soit en déclenchant les actions de sons système (acteur primaire) soit en étant utilisé par ton système (acteur secondaire)

le plus important ce ne sont pas les acteurs, mais les UC eux mêmes car les UC disent ce que doit faire ton applications. En d'autre temps les UC s'appelaient "cahier des charges".

[Laplix]

Merci bien Bruno.

En effet, je crois que je vais essayer de limiter cette partie de la modélisation. Quant à mes Use cases, ils ne sont pas vraiment compliqués : créer une requête SQL, lire les données de la BDD, manipuler les données de la BDD.

Je crois que je vais plutôt me concentrer sur l'analyse et la conception des classes.

Merci encore

[wiztricks]

Le seul acteur que je voyais était "Application" quoique le web 2.0 demanderait peut-être du XML ou du JSON. De plus, selon ce que dit bruno_pages, les gestionnaires de bases de données peuvent également être des acteurs secondaires?

XML ou JSON précisent comment seront échangées les informations.
Nous sommes dans les composants et les interfaces, le "comment" ou "avec".

@wiztricks Si je comprends bien, une librairie n'a pas vraiment d'acteur? Les cas d'utilisation seraient plutôt une simulation de personnes physiques écrivant des applications et utilisant la librairie? Ai-je vraiment besoin de simuler cela?

bruno_pages semble dire que même des applications peuvent être des acteurs?

Ce que je voulais dire c'est que mettre des "acteurs" dans la conception d'une librairie me semblait inutile car vous serez de toutes façon obligé de décrire composants et interfaces.
Par contre, vous devrez sans doute faire des exemples d'utilisation et donc imaginer une application qui utilise votre librairie.

Pourrions-nous dire alors que j'ai, au fond, deux acteurs :
* un acteur traditionnel (site web traditionnel, application web traditionnelle, framework web traditionnel et même application GTK
* un acteur web 2.0 qui aura besoin de recevoir ses résultats dans un format XML ou JSON

Il y a surtout des variations dans le format des données de l'interface avec le composant appelé librairie.

Ou bien, effectivement, ma librairie n'a pas d'acteur et que je dois simplement me concentrer sur le design des classes elles-mêmes (interface, héritage, etc.) Et dans ce cas, ai-je vraiment besoin de faire des diagrammes UML???

Il y a les spécifications externes dans lesquelles sont décrits les composants qui interagissent avec la librairie - appelez cela "acteurs", UML est assez "souple". Puis les spécifications "internes", qui vont détailler l'implémentation de la librairie. Dans les deux cas, vous pouvez utiliser des diagrammes UML pour "illustrer" ou montrer ce que vous voulez réaliser.

Nota, n'oublions pas que tout ces détours n'ont d'intérêt que dans la mesure ou ils nous permettent de coder (encore un modèle) de façon plus sûre.
-W