Interface IHM : Modélisation de comportement [Résolu]

[kolodz]

Bonjour,

Je voudrais réaliser un IHM "simple" permettant de décrire le comportement d'objet.

Par exemple, on a :

Joueur :
=> Jauge Xp
=> Nombre Niveau

Je voudrai qu'un utilisation soit capable de créer le comportement suivant :

Code :

1
2
3
4
Si Jauge Xp pleine
Alors :
Vider Jauge Xp
Ajouter 1 à Niveau

*En supposant, ce qui est en gras, comme des propriétés/actions prédéfini.

Je cherche un modèle objet assez simple avec une interface IHM tout aussi simple. Pour que l'utilisateur ne soit pas trop perdu.

Des idées ? Des remarques ?

Cordialement,
Patrick Kolodziejczyk.

[Richard_35]

Bonjour Kolodz,

Je ne suis pas sûr de comprendre... : l'IHM est une chose, la modélisation en est une autre. L'IHM se base sur la modélisation (MCD), elle-même se basant sur des règles de gestion.

Ces règles de gestion semblent être les suivantes :

1 joueur n'est qu'à 1 et 1 seul niveau
1 niveau peut être attribué à plusieurs joueurs

1 joueur peut posséder plusieurs objets
1 objet peut être possédé par plusieurs joueurs

1 objet peut posséder plusieurs comportements
1 comportement ne peut être attribué qu'à 1 et 1 seul objet

Jusque là, tout va bien ?

[kolodz]

Je ne suis pas sûr de comprendre... : l'IHM est une chose, la modélisation en est une autre. L'IHM se base sur la modélisation (MCD), elle-même se basant sur des règles de gestion.

Je n'ai pas l'IHM, pas encore de modèle pour cette partie. Et pour ce qui est des règles de gestions, cela peux se résumé en :

Permettre la création de comportement, le plus facilement possible et le plus complexe possible.

Du coup, j'essaie de voir quelle IHM avec quel modèle serai le plus efficace pour cela.

Pour le coup, c'est un peut plus compliqué que ça :
La "classe" Joueur est un objet de la classe MyObject, qui contient une liste de propriétés et un nom :

Code :

1
2
3
4
class MyObject extends MyProperty {
	private String name;
	private Map<String, MyProperty> properties;
}

Donc :

1 joueur n'est qu'à 1 et 1 seul niveau
1 niveau peut être attribué à plusieurs joueurs

Le niveau est une propriété de de la classe joueur.

Oui pour la première ligne.
Non pour la seconde ligne.

1 joueur peut posséder plusieurs objets
1 objet peut être possédé par plusieurs joueurs

Oui pour la première ligne.
Non pour la seconde ligne.

1 objet peut posséder plusieurs comportements
1 comportement ne peut être attribué qu'à 1 et 1 seul objet

Oui pour la première ligne (sur la cardinalité).
Non pour la seconde ligne (sur la cardinalité).

Je veux que les comportements soit séparer des objets, du moins le plus possible.
Pour moi, un comportement s'applique à un objet, plus qu'un objet possède un comportement.

Le sujet est donc assez large...

[Richard_35]

Envoyé par Kolodz

Et pour ce qui est des règles de gestions, cela peux se résumé en :
Citation:
Permettre la création de comportement, le plus facilement possible et le plus complexe possible.

==> ce n'est pas une règle de gestion, c'est un souhait.

Envoyé par Kolodz

Le niveau est une propriété de de la classe joueur.

==> OK.

1 joueur n'est qu'à 1 et 1 seul niveau
1 niveau peut être attribué à plusieurs joueurs

==> hum... plusieurs joueurs ne peuvent pas avoir le même niveau (plusieurs joueurs au niveau 5, par exemple) ?

Envoyé par Kolodz

1 joueur peut posséder plusieurs objets
1 objet peut être possédé par plusieurs joueurs
Oui pour la première ligne.
Non pour la seconde ligne.

==> est-il impossible que plusieurs joueurs possède une jauge (je ne parle pas de la jauge n°1, n°2 ou n°N) ?

Nous reprendrons un peu plus tard (j'ai oublié une strate).

[kolodz]

Merci pour l'intérêt que tu porte à ce sujet. Cela m'aide beaucoup dans ma réflexion.

==> ce n'est pas une règle de gestion, c'est un souhait.

J'avoue ne pas savoir comment l'exprimer. Le comportement des objets "MyObject" doit être déterminer par l'utilisateur.
Il y aurait bien la possibilité d'avoir l'utilisateur demande un comportement et un développeur le réalise. Mais je trouve cette idée dépassé et contre productif.
Je reste donc sur une solution où l'utilisateur saisi le comportement. C'est là que cela se complique...

==> hum... plusieurs joueurs ne peuvent pas avoir le même niveau (plusieurs joueurs au niveau 5, par exemple) ?

Si, c'est possible, mais cela ne pointe pas vers la même instance "niveau".

Cordialement,
Patrick Kolodziejczyk.

[Richard_35]

Envoyé par Kolodz

Le comportement des objets "MyObject" doit être déterminer par l'utilisateur.
Il y aurait bien la possibilité d'avoir l'utilisateur demande un comportement et un développeur le réalise. Mais je trouve cette idée dépassé et contre productif.
Je reste donc sur une solution où l'utilisateur saisi le comportement. C'est là que cela se complique...

==> nous sommes au niveau conception d'un modèle données : la méthode de remplissage des données (qui fait quoi et comment ?) vient après.

Envoyé par Kolodz

Si, c'est possible, mais cela ne pointe pas vers la même instance "niveau".

==> idem : ne parlons pas d'instance ni de classe, pour l'instant.

En revanche, il faut valider (ou pas) les (vraies) règles de gestion suivantes (telles que comprises) :

1 même joueur ne peut être qu'à 1 et 1 seul niveau
1 niveau peut être attribué à plusieurs joueurs différents

1 objet ne peut être que d'1 et 1 seul type (type "jauge", par exemple)
1 type d'objet peut qualifier plusieurs objets (type "jauge" : "jauge n°1", "jauge n°2", ...)

1 joueur peut posséder plusieurs objets
1 objet ne peut être possédé que par 1 et 1 seul joueur

1 type d'objet peut posséder plusieurs comportements (vide, pleine, pour la jauge)
1 comportement ne peut être attribué qu'à 1 et 1 seul type objet (vide ne s'applique que pour les jauges)

1 comportement ne peut déclencher qu'1 et 1 seule action
1 même action peut être déclenchée par plusieurs comportements

Encore une fois, "qui saisi et comment ?" est une autre histoire.

[kolodz]

==> nous sommes au niveau conception d'un modèle données : la méthode de remplissage des données (qui fait quoi et comment ?) vient après.

Justement, la conception que je fait est la conception d'un méta-modèle. Ce méta-modèle doit permettre la description des objets d'un jeu et la description du comportement de ces objets.
Mon modèle contient donc deux éléments majeurs : les objets et les comportements.

Je sais que la description d'un comportement nécessite la connaissance de l'objet qu'il manipule.

Hypothétiquement on a pour un MyObjet :

Les propriétes.

Les jauges :

Exemple : De vie, d'expériance, d'amitié, de bien être
Une valeur
Une borne inférieur
Une borne suppérieur

Les nombres :

Exemple : L'argent, la taille, l'age, le jour de naissance, point de force
Une valeur

Les textes :

Exemple : Nom, Prénom, email, description, biographie
Un valeur

Un Enum :

Exemple : profession, Etat{Bon,Moyen,Mauvais,DETRUIT}
Une valeur
Une référence vers une liste

Les Listes :

Exemple : Contenu d'un sac, liste de mission, liste de course, liste de nom, liste de nombre

Les objets/ type complexe :

Exemple : date de naissance, un sac, un arbre de talent
Un objet des propriétés

Cela reste un définition des types de base classique, mais il en faut bien une. Point de vue modélisation, je n'ai aucun problème avec ça.

Après il y a la définition du comportement ou des Règles :

Les Règles :

Exemple : La gravité, la mort
Un déclancheur

Se déclanche sur altération d'une propriété ou par action de l'utilisateur
1. Si La jauge de vie < 0 ------- Si l'etat passe de Bon à Detruit

Un comportement

2. Alors passe de l'etat VIE à MORT ------ ALors passe de l'etat UTILISABLE à INUTILISABLE

Pour cette partie, c'est plus délicat.
Le déclencheur est un peu complexe à modéliser si on permet les et/ou. Mais rien d'insurmontable.
Pour le comportement, en lui-même, c'est un peu plus compliqué. Et à chaque fois que je reviens à cette partie, j'arrive soit à quelque chose de trop compliqué pour l'utilisateur (doit saisir un code) ou trop complexe à présenter à l'utilisateur.

D'où ma première question.

Cordialement,
Patrick Kolodziejczyk.

[Richard_35]

Bonsoir Kolodz,

Si j'ai bien compris, tu veux "variabiliser" au maximum (objectif des méta-modèles). Mais, plus tu "variabilises" et plus tu

Envoyé par Kolodz

arrive(s) soit à quelque chose de trop compliqué pour l'utilisateur (doit saisir un code) ou trop complexe à présenter à l'utilisateur

Il faut donc déterminer jusqu'à quel niveau tu veux laisser aller tes utilisateurs :

• créer des MyObject ;
• créer des propriétés des MyObject ;
• créer des types de valeur ;
• créer des règles (si xxx, alors yyy et zzz) ;
• ...

[Hephaistos007]

En gros tu es en train de définir ton propre langage, que nous baptiserons KML (Kolodz Modeling Language ).

A y regarder de plus prés, ce langage est constitué de 2 sous-langages :

• un langage de définition d'entité
• un langage de règles (s'appuyant sur les entités définies)

Maintenant, d'un point de vue syntaxique, il faut savoir quels sont les mots clé du langage KML, et les autres. Et là, ca semble pas très clair. Je te propose d'imaginer que le langage KML ressemble à cela (mot-clés en gras)


//Langage de définition
entity Joueur {
property jauge:entier;
property level:entier;

action pleine:booleen { test(jauge == 45); }
action vider { jauge<-0; }
action ajouter #n { jauge<-jauge + n; }
}

//Langage de règle
rule R1 {
context : Joueur;
pleine => vider, ajouter 2
}

Tout ceci est parfaitement imaginable et peut être mis en oeuvre dans des environnement comme EMF comme je l'explique ici : http://olegoaer.developpez.com/tutos/model/WDL/


Enfin, tu remarqueras que le langage KML est finalement assez proche d'un langage à classe comme Java par exemple. Quel intérêt alors de ré-inventer la roue ?
il manque le langage de règles ? soit, alors JRules (Java Rules) fera parfaitement l'affaire...

[kolodz]

J'avoue ne pas avoir songer à cette approche. Pourtant, je l'ai déjà pratiquer.

Je pensais que cette approche était trop technique pour être utiliser par un non initié.
Mais la présentation de ton tutoriel me fait penser qu'il est possible d'avoir quelque chose d'assez propre et même de jolie.

Sachant que le bût est de présenté ce langage comme un texte de loi. La constitution du jeu qu'il définit en quelque sorte.

Je vais voir si je trouve ce qu'il faut en php.

Merci pour cette intervention !

Cordialement,
Patrick Kolodziejczyk.

Edit: Je marque comme résolu. Car la problématique de la mise en œuvre n'est pas le sujet ici.